Extension:Header Tabs/Roadmap/LQT Archive 1

=Next release= The next planned release is: 0.9.1 To contain any bugfixes from the slew of new features introduced in 0.9.

=Planned future features= These features are being considered by the developers of the extension for inclusion. This does not mean they cannot be worked on by anyone, feel free to submit a patch on the talk page if you develop the feature.

Add tab
A SpecialPage that is similar to the AddSection for talk pages should be created. It should allow the editor to select where the new tab will be inserted (not just at the end) and should not require them to input the page name where the tabs will show up. The ideal place for the link would likely be a new tab added with a '+' sign. This however causes some problems as it will only be shown if 2 tabs are already present. For this reason an option for where the add tab link shows up may be preferable. Please ensure to enable keyboard shortcuts, have a tooltip hint and i18n the whole thing. An alternative location would be as a portlet link in the Vector/Monobook skin at the top. Some thought on how this might integrate with future skins like Athena would have to be considered. The talk page new section code has already been evaluated to see if we could re-use it, unfortunatly it requires editing of a Mediawiki property to make it generate top-level headers instead of 2nd level (also affecting new sections on talk pages) and only allows new sections to be added to the end. Adding a custom tab to jquery ui is non-obvious, you have to manually create the DOM element to the UL, apply the jquery classes and add the jquery hover properties. A new configuration setting  should be added and defaulted to on. New magic words  and   should be added. --Olivier Beaton 17:32, 13 December 2011 (UTC)

Edit tab
New magic words should be added to change when the edit tab link is shown,  and. --Olivier Beaton 17:32, 13 December 2011 (UTC)

Tab TOC
The tab TOC should by default insert itself after the first paragraph of the tab content (unless there are none, before the first header).

New magic words should be added to change when and where the tab TOC is shown:,   and.

The way we generate the TOC could be improved. Currently we clone a  object and re-run   on already formatted content which can give unpredicatable results and break our TOC generation (for example, we use different parsing code for 1.17 and 1.18). An alternative might be  however this function is not used in MW, so may be dropped. The original plan as we understand it is that the function was supposed to replace the standard code. --Olivier Beaton 17:32, 13 December 2011 (UTC)

Semantic FactBox
The semantic FactBox tab does not work since the move to jquery, we should fix that. --Olivier Beaton 17:32, 13 December 2011 (UTC)

Tag i18n
The  and   parser function names could be i18n. We should always support these standard names however additional localized names would be ideal.

Reduce js/css load
We may be able to only load our js and css styles if tabs are actually shown. Currently we do if the extension is enabled, instead of on a per-page basis. Investigating how this could affect page caching would be needed, and to ensure we never add the files twice to RL. --Olivier Beaton 17:32, 13 December 2011 (UTC)

Multiple tab lists
It may be possible to specify multiple tab areas for the same page. It's debatable if this is even a good idea UI wise, however it should be possible to make it generate a custom ID, at which point the user may want to even have the different tab boxes use different styles. The  tag could be made to have a closing tag, and attributes specifying the style and id. Changing the ID may have serious repercussions on how we define styles. This would have some RL implications and ensure no duplicate loading. --Olivier Beaton 17:32, 13 December 2011 (UTC)

$htDefaultFirstTab and $htRenderSingleTab
There is a problem if both of these configuration settings are enabled. Because the headertabs is done in the parser, there is no way to know if what is being modified is the article text or something like the last modified line. By turning on both these options you will end up with tabs appearing everywhere in your skin that is passed to the parser, definitely not the intended behaviour. It's unclear how to fix this. --Olivier Beaton 20:04, 13 December 2011 (UTC)

On-wiki style change
It should be possible to add an attribute to  to allow you to specify which style to use on-wiki for only that page. This would have some RL implications and ensure no duplicate loading. --Olivier Beaton 17:32, 13 December 2011 (UTC)

jquery ui tabs
jQuery is changing the API for the tabs. Notably the .length property will disappear, and our current javascript code will likely break. We need to update to the new way of doing things when MW does, and watch trunk closely.--Olivier Beaton 20:08, 13 December 2011 (UTC)

Additional styles
Cloning the look of the YUI tabs should happen, so that wikis currently using YUI tabs don't get an appearance change when upgrading. You could call this 'yui' or 'classic'. Additionally, we should look at if we can support jquery ui's themeroller somehow. --Olivier Beaton 20:10, 13 December 2011 (UTC)

=Feature requests= __NEWSECTIONLINK__ If you would like to see a new feature added to Header Tabs, or have developed your own feature not listed above, please mention it here. If you have a patch file, please link to it directly. Remember to sign your comments!

Default view tab
We would like to see a functionality where one can define a default view tab per definition (and not using LocalSettings). When using  instead of going to the first tab the default="foo" would define a default tab that is viewed first. For example using HT in SForms where the general textarea needs to come last, means that the user always have to go through other tabs before he/she can start writing and having a possibility to declare  would save some time for the user. -- MWJames, 15:35, December 13, 2011