Extension:Header Tabs/Roadmap/LQT Archive 1

Next release

The next planned release is: ?

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 $htAddTab should be added and defaulted to on. New magic words __NEWTABLINK__ and __NOTABLINK__ 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, __EDITTAB__ and __NOEDITTAB__. --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: __NOTABTOC__, __TABTOC__ and __FORCETABTOC__.

The way we generate the TOC could be improved. Currently we clone a $parser object and re-run formatHeaders 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 ParserOptions::generateTOC 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 <headertabs/> and {{#switchtablink: 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 <headertabs/> 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 <headertabs/> 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

If you would like to see a new feature added to Header Tabs, or have developed your own feature not listed above, please use the start discussion link here. If you have a patch file, please link to it directly. This is for feature requests only, support requests should still go to the talk page.