I was thinking that perhaps it's time to remove the "format missing links as link?" option
1: It's ancient
2: few people probably still use it (let's not count users who haven't edited in the past 3 years).
3: It's a confusing option in your prefs, if you are a n00b.
4: we can create gadgets or provide users with a css example for their common.js for those who insist
5: it's ancient.
Version: 1.18.x
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T62557 Update docs to deprecate $wgDefaultUserOptions['highlightbroken'] | |||
| Resolved | None | T29619 Remove ? mode for missing links |
a.d.bergi wrote:
+1.
The Gadget would look like that: (CSS)
a.new::after { content: "?"; }
Have statistics been gathered yet on how many users (that aren't inactive more than the last N months) use this preference one some of the largest projects ? Preferably taking different groups into account (ie. commonswiki or metawiki with users from all over the wiki land) and en.wikipedia for good measure.
Either way, perhaps start by hiding the preference via WMF configuration
$wgHiddenPrefs[] = 'highlightbroken';
If no major problems rise (ie. usecases for this preference we might have missed) we can always remove it permanently later on.
Just FYI: I haven't received any complaints about the dozens of options I've hid in twn.
I would actually use this feature had it been implemented differently, i.e. not implemented in CSS but to have ? displayed as a part of HTML.
I love editing wiki with w3m (the text browser) and it's the only feature that's missing - you can't tell blue links from red links with this browser,
so I had to check manually all the links I added for typos.
Having a non-CSS question mark after link would really help. I could also imagine it could help in some accessibility situations, where advanced CSS2 is not available.
In its current form it's just a visual gimmick and useless. I'd love to see it back in the HTML form. I now it's difficult because of the way we currently cache compiled parser output, or isn't it?
a.d.bergi wrote:
Does your text browser support JavaScript? A js-gadget is also possible, of course, but it would show up on the page a bit slower. And, mainly, the code might be 2 lines longer than my css-example-snippet :-)
I think discussing how hard or easy it is to replicate it in site or user js/css is quite useless. If this feature has has a purpose that is still valid in 2011 and people make use of it, then it should be done on the server side, not the client side. Wether in core or from an extension is a separate question, but not a gadget imho.
However, if statistics show that it is barely used, and/or UX experts say that this alternative interface is not improving anything, then we might as well remove it.
(In reply to comment #6)
I think discussing how hard or easy it is to replicate it in site or user
js/css is quite useless. If this feature has has a purpose that is still valid
in 2011 and people make use of it, then it should be done on the server side,
not the client side. Wether in core or from an extension is a separate
question, but not a gadget imho.
Note, we don't really do this server side as it stands. I agree it might make sense as an option if we actually output the question marks in text (for text-browsers), but all we do is add an extra css rule when the pref is selected.
It'd be really nice to get stats for _all_ the preferences. There's several remove pref X bugs, which can't really be dealt with with no statistics
(In reply to comment #7)
It'd be really nice to get stats for _all_ the preferences. There's several
remove pref X bugs, which can't really be dealt with with no statistics
Is there a reason not to make aggregate information from all wikis available on a regular basis? Filed an RT requesting this: http://rt.wikimedia.org/Ticket/Display.html?id=1761
Why don't we make this feature actually *do* something?
I understand caching issues with storing parser results etc., but maybe those problems are irrelevant given there is probably pretty small community of text/other non-color, non-CSS browsers around?
Lack of underline color in text browsers and no alternative like "?" *is* a problem.
Removing this feature reduces chances to fix this problem properly in the future to zero.
(In reply to comment #11)
Can we always output the ? and remove it with css?
My original thought was that doing that would lead to ? showing up in every Copy & Paste, but it seams that was actually a bug and it was fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=39098
(In reply to comment #9)
1 year and no statistics, so being expeditious. Removed in r111861
We definitely had stats before for a difference preference. Can't we use this to send out a message to active users (if they really are that few?).