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.

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.

attachment 29672.patch ignored as obsolete

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 :)

Working patch (use canonical)

Utilise canonical names as provided above.

Attached:

Looks good. Committed in r91869

a.d.bergi wrote:

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