Mailing List Archive

Universal Edit Button: Remove redundant rel="edit" link head
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
Re: Universal Edit Button: Remove redundant rel="edit" link head [ In reply to ]
> […] 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 mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/