Finding an element and then finding out which tab it's in *should* be pretty straightforward; I'm adding bug 27559 as a dependency here since this should be just an extension of the code needed there.

See also wm_reveal_for_hash() of MobileFrontend, which does something similar.

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/MobileFrontend/javascripts/application.js?revision=101737&view=markup

Dan: Isn't this kind of fixed by being able to link to the first section in a tab, e.g. for "Appearance" https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-rendering ?
I'd close this as RESOLVED WORKSFORME as it seems to be good enough.

This is now possible by linking to Special:Preferences#tabname.

Reopening: linking to a tab and linking to a preference are not the same thing. Some preference tabs are a jumble of dozens of esoteric options, forcing the user to figure out which one they have to change is not helpful at all. There should be a way to link to a specific preference, and that should create some sort of visual highlighting to that preference.

The simplest implementation would be using Special:Preferences#<input element id>, then a script would locate the input element, open the parent tab, scroll the element into view, and add a yellow background to its container element ( $(element).closest('[id^=mw-htmlform-field-]') at first glance).

You can now link to setting fieldsets via their ID, which should be sufficient for deep-linking for power users, for example https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rc-optoutrc

From a user perspective I don't think it makes sense to fine-grain this even further down to a specific setting, as the context is useful to be shown as well.

We won't expose a link marker though as it would unnecessary clutter the interface for a rarely used power user feature to all users.

In T34811#4567498, @Volker_E wrote:

From a user perspective I don't think it makes sense to fine-grain this even further down to a specific setting, as the context is useful to be shown as well.

The use case is help pages which link to a specific setting (which then the user has to find in the not-exactly-user-friendly mess of Special:Preferences). Which might have different text than the help page (since those are rarely kept in sync with translations) etc.

An anchor would not be a good solution for that, sure; probably some kind of JS-based highlighting should be used instead. Select the right tab, scroll it if necessary so the preference is within view, and then change the background color of the preference to light yellow, or something like that.

For actually supporting direct links to preferences, see T295302: Provide a way to highlight a given option in Preferences.