Last modified: 2011-07-19 18:40:24 UTC
Since r81573 the tabs on Special:Preferences has anchors, but the tab index is used to build that anchors. When install a extension which create an own tab some links can get broken, because the index can change. Please use the name of that tab to build the anchor, that cannot break, because a new tab has another name. So you can use [[Special:Preferences#preftab-edit]] or so. Thanks.
I'm also marking this as a blocker on bug 27559 (saving the currently selected tab across submissions); while not strictly a requirement, making the hashes more actively used would benefit from also making them link-friendlier by using nice ASCII english words.
Created attachment 8742 [details] Working patch (remove spaces only) This patch should do the trick. Obviously, any level of "normalisation" is possible - it's a trade off between readability/clashes/potentially breaking the anchor. I've opted for low level normalisation - only spaces, hashes and hyphens. The JavaScript-disabled version is unaffected. Tested in latest FF, IE and Chrome; any-which-way it's a simple patch.
Problems with patch: 1. HTML4 only allows very limited characters for ID's. I don't think browsers hickup on that though, since it's a very common mistake. 2. Links will be Userlanguage dependent. Something like "Go to this link ../Special:Preferences#Editing , then change X and click save" etc. will break if the others user lang is italian.
(In reply to comment #3) > 2. Links will be Userlanguage dependent. Something like "Go to this link > ../Special:Preferences#Editing , then change X and click save" etc. will break > if the others user lang is italian. Using the canonical/technical name of the tab should be ok, because in other situation it is also used (URL param, log types and so on)
Thanks for the review. I shall have a prod around regarding Canonical names. With respect to allowed characters, all I can find is "restricted to ASCII characters". Elsewhere in Wikipedia we use a fairly heavy process to ensure adherence to this. On the other hand, canonical names are almost certainly going to be written in English. So it's probably fine.
Okay, so the major problem is that canonical names are not exposed to the JavaScript. There seems to be no easy way of exposing them, either. The form extends HTMLForm, and uses its abstracted functions. As a consequence, which massive overriding HTMLForm, there's no way for the PHP to know which <legend>s the JavaScript is going to need metadata about. That's my take, anyway.
(In reply to comment #6) > Okay, so the major problem is that canonical names are not exposed to the > JavaScript. Here you go: r91757 :)
Created attachment 8763 [details] Working patch (use canonical) Utilise canonical names as provided above.
Looks good. Committed in r91869
Nice, but could you please add a legacy function for old links (from FAQ etc, links that help-seeking users found in archives)? Maybe something like (untested) var tab, hash = window.location.hash; if( tab = hash.match( /^#preftab-(.+)/ ) ) { var $tab = $( hash + '-tab' ); if (! $tab.length && tab[1]) $tab = $('#preftoc a').eq(parseInt(tab[1])); $tab.click(); }
(In reply to comment #10) > Nice, but could you please add a legacy function for old links (from FAQ etc, > links that help-seeking users found in archives)? Maybe something like > (untested) > var tab, hash = window.location.hash; > if( tab = hash.match( /^#preftab-(.+)/ ) ) { > var $tab = $( hash + '-tab' ); > if (! $tab.length && tab[1]) > $tab = $('#preftoc a').eq(parseInt(tab[1])); > $tab.click(); > } For backward compatible see r91869#c19481
