As usual with experimental standards that ship in the wild with "temporary" semantics, the temporary semantics become defacto standard and the "future" standard remains reserved for theoretical future use.
In T21165 https://phabricator.wikimedia.org/T21165#6946526 I compare half a dozen implementations and specs and observe that they all support rel="alternate" whereas only one supports (in addition to rel="alternate") also rel="edit".
Thus I'm concluding that rel="edit" is a dead standard and that at least for right now there is no benefit to MediaWiki outputting it. There is a cost for us to output it, but there is not really any signficant cost for clients to support both, and supporting both is mandatory either way for the theoretical future standard to be adopted.
If in another ten years notable clients actually supported the supposed newer standard by then, we could switch at that time.
Task: https://phabricator.wikimedia.org/T21165 Commit: https://gerrit.wikimedia.org/r/722485
A potential argument could also be made that it should be removed entirely. I myself have never understood why one would want a browser extension to display an Edit button outside the viewport. It seems unappealing from a UX perspective and for me personally would likely fade into "banner blindness" and notice if it were detected and/or notice it too much if it tries to get my attention on any editable page. In any event, while I would love to hear from people who find this useful, I am /not/ proposing its removal.
-- Timo
[…] I myself have never understood why one would want a browser extension to display an Edit button outside the viewport. It seems unappealing from a UX perspective and for me personally would likely fade into "banner blindness" and notice if it were detected and/or notice it too much if it tries to get my attention on any editable page.
Have you been able to check if screenreader software possibly does something useful with these rel="…" attributes?
For me this was always the main motivation to provide e.g. meaningful <link rel="prev"> and <link rel="next"> in addition to the pagination links that can be found in the content of a page. Not necessarily to "display buttons outside of the viewport". But for users with visual impairments that can't use a mouse, but have dozens of keyboard shortcuts memorized instead. The fact that these links are displayed in a toolbar is more secondary. What matters is that they have the same shortcuts assigned, no matter what the website is.
Even if it turns out that screenreaders are the only tools that do something with a <link rel="…">, and even if screenreaders only make up zero point whatnot percent, I believe it's worth it.
Remember, accessibility is a process, not a state you can reach.
Best Thiemo
wikitech-l@lists.wikimedia.org