tab-navigation and links?

[fred-wang]

cc @rwlbuis

mathml/relations/html5-tree/tabindex-002.html checks that links are focusable as described in https://mathml-refresh.github.io/mathml-core/#focus ; however it also refers to https://html.spec.whatwg.org/multipage/interaction.html#focus which mentions that <a> are sometimes focusable area "depending on platform conventions"

It seems on macOS a HTML links are not focusable: https://bugzilla.mozilla.org/show_bug.cgi?id=1571487#c30

I don't know what's the general rule (what about XLink's href, SVG <a> ?) but MathML should probably be aligned on whatever existing rule for consistency.

Also, it seems sometimes links are not focusable on Chromium: https://github.com/Igalia/chromium-dev/issues/50

[NSoiffer]

The "platform convention" statement also appears in the tabindex portion of the whatwg doc:

Modulo platform conventions, it is suggested that the following elements should be considered as focusable areas

a and link are among the listed elements.

I checked two sources about SVG and neither say anything about focus:

• element
• xlink:href

However, the SVG spec says this about links out of SVG:

User agents must also ensure that all links are focusable and can be activated by keyboard commands.

I think the HTML specs should be considered more authoritative and so platform conventions should win out.

[fred-wang]

Thanks for checking this. Yes, I think MathML links should really follow HTML links and so respect platform conventions.

[fred-wang]

cc @bzbarsky @emilio @rniwa

[bkardell]

Potentially controversial, but a few discrete but related things I would like to throw out...

1. If we were creating MathML today, and there was no legacy - we would almost certainly match HTML/SVG and do this with a single, proper <a> thing, not as any of the options that we are discussing here.

2. If you had to do one in core, using existing MathML elements, it probably would have to be <mrow> for reasons @fred-wang explained. But this will barely match any existing uses and i don't think it's necessarily intuitive either (personally). This means, in practice, you have two options:

• convert your existing stuff, somehow, to this mrow based thing.
• polyfill your existing stuff

3. Given proper DOM abilities we can totally 'polyfill' support on any or all of these options for most uses. I think polyfill is a bad name in this use because ultimately that just means "we can make it basically work and do the thing you meant". Here's a quick take https://codepen.io/bkardell/pen/RwNXXjB that illustrations basically what I mean.. This is a pretty decent stand-in for what you probably want to do and you could improve it pretty easily too.

4. There are some complications and implications of whatever we decide to do - the thing that is least complicated and has the fewest implications on things we can do in the future might be to take this all as an opportunity to align with the platform here, fix the DOM IDL, use some JS to bridge old gaps and add a proper <a> like everything else....

But idk... maybe that's way off/not viable.

[davidcarlisle]

@bkardell wrote

Potentially controversial, but a few discrete but related things I would like to throw out...

1. If we were creating MathML today, and there was no legacy - we would almost certainly match HTML/SVG and do this with a single, proper <a> thing, not as any of the options that we are discussing here.

It's funny how things turn out. MathML 1 and 2 didn't allow href= on everything and links used a specific <maction> wrapper element. We went with href= in MathML3 to follow the prevailing trends (svg and xhtml1 allowing xlink:href on everything, xhtml2 allowing href= on everything) and also because a single href attribute was a lot nicer than the verbose markup required for maction, if you just wanted a link.

From a markup perspective allowing href still seems quite natural, and a natural counterpart to allowing id= on anything, rather than the original html model of requiring <a name=...> to set a link anchor. However can't disagree that the platform for whatever reason didn't follow that idiom.

A quick check in our current manual

bash-4.3$ grep  -o -r '<m[intr][^<>]*href=' | wc -l
199951

suggests we have ~200 thousand mi mn mtext or mrow with an href attribute, so wrapping each of those in an <a href would be a trivial change in the build scripts but adding a fair bit of extra markup for not much gain.

That said, if allowing (essentially) all mathml elements to carry links and so have to be involved in rules for tab focus etc is an implementation burden, then introducing <a href= is not something that I'd necessarily object to.....

2. If you had to do one in core, using existing MathML elements, it probably would have to be <mrow> for reasons @fred-wang explained. But this will barely match any existing uses and i don't think it's necessarily intuitive either (personally). This means, in practice, you have two options:

* convert your existing stuff, somehow, to this `mrow` based thing.

* polyfill your existing stuff

For me as someone generating mathml documents, changing to put all links on mrow or all links on a new <a> element, is about equal work so no real preference there. I quite strongly prefer the existing markup so if the change is just to make implementation more streamlined chose whichever is the simplest implementation...

1. Given proper DOM abilities we can totally 'polyfill' support on any or all of these options for most uses. I think polyfill is a bad name in this use because ultimately that just means "we can make it basically work and do the thing you meant". Here's a quick take https://codepen.io/bkardell/pen/RwNXXjB that illustrations basically what I mean.. This is a pretty decent stand-in for what you probably want to do and you could improve it pretty easily too.

yes although that's an awful lot of elements to be selected and links activated in our manual.. (Although the speed at which modern browsers do those kinds of updates is pretty impressive:-)

2. There are some complications and implications of whatever we decide to do - the thing that is least complicated and has the fewest implications on things we can do in the future might be to take this all as an opportunity to align with the platform here, fix the DOM IDL, use some JS to bridge old gaps and add a proper <a> like everything else....

As I say above I wouldn't rule it out but what I don't actually have a feel for from your description is whether allowing href everywhere is actually causing implementation issues or whether you just think it looks odd given how html and svg evolved. (Even if it's only the latter, that isn't necessarily not a reason to change, making html-svg-mathml look like a coherent markup language for web documents is a good aim in itself)

But idk... maybe that's way off/not viable.

Not so far off that it can't be considered, I think....

[NSoiffer]

Indeed, we would follow HTML if we were creating a fresh spec, but that ship has sailed. We can follow it in core at the cost of having to write polyfills for what is likely a relatively common use case (as per what @davidcarlisle found for his company's usage.

I agree with David that if this is a significant implementation issue, then we could change the way things happen core. However, the more core diverges from the full spec, the more problematic the whole MathML spec becomes. We could introduce <a> into full, but then there are two ways to do the same thing which is not a good idea.

@bkardell: isn't there a problem with your example code in that it always creates a new element every time the element is activated? I suppose I shouldn't be nit picking because you were just trying to show how one could do a "polyfill" (do you have a better name? Neither the MDN def nor the person who coined term (linked from MDN page) say anything about not modifying the DOM, so maybe it is proper usage?)

[davidcarlisle]

@NSoiffer

We could introduce into full, but then there are two ways to do the same thing which is not a good idea.

My preference would be to keep allowing href on at least token elements and mrow, but if we do add <a> to core I think we'd have to have it in full as well as I think it should be a requirement that a document valid to core is always valid to full.

[rwlbuis]

As I say above I wouldn't rule it out but what I don't actually have a feel for from your description is whether allowing href everywhere is actually causing implementation issues or whether you just think it looks odd given how html and svg evolved. (Even if it's only the latter, that isn't necessarily not a reason to change, making html-svg-mathml look like a coherent markup language for web documents is a good aim in itself)

I think it is the latter, as implementation has no issues, the code just moves to the generic MathElement rather than some specialized MathAnchorElement.

[fred-wang]

I haven't read everything in details, but just to be clear: the href support is implemented in the element classes it has nothing to do with layout classes. And the implementations are basically just duplicating what is done for SVG/HTML <a> element.

So strictly speaking, it does not cause any implementation issue for the rest of the MathML layout. However, as @emilio explained in w3c/mathml#125 the fact that all elements are currently potentially links have some implications which are likely to get some push back from web engine & WHATWG reviewers. For the record, @rwlbuis uploaded https://chromium-review.googlesource.com/c/chromium/src/+/2035979 but we are probably not going to upstream it for now as it has lowest priority and open questions to resolve first.

I didn't notice that @bkardell's polyfill was adding a <a>. I was wondering whether it could be just done by adding proper listener, tabindex and style. Note that a typical performance issue is when a polyfill requires reflowing many elements in the page ; not sure if that's the case here.

[fred-wang]

As I say above I wouldn't rule it out but what I don't actually have a feel for from your description is whether allowing href everywhere is actually causing implementation issues or whether you just think it looks odd given how html and svg evolved. (Even if it's only the latter, that isn't necessarily not a reason to change, making html-svg-mathml look like a coherent markup language for web documents is a good aim in itself)

I think it is the latter, as implementation has no issues, the code just moves to the generic MathElement rather than some specialized MathAnchorElement.

I think @emilio mentioned that in Gecko having the stuff in the generic MathMLElement means that we have several link-specific class members for all MathML elements, which can increase memory usage.

[bzbarsky]

Also, any time the document base URL changes (e.g pushState), all links have to be invalidated. This means walking the list of all potential links, and if that means all MathML elements that can be a performance issue. There are some things that can be done to optimize this, but they're fragile and complicated.

Basically, links are a lot more complex in both space and time than people seem to think. Allowing all MathML elements to be links adds a good bit of overhead, or implementation complexity, or both.

[rwlbuis]

Also, any time the document base URL changes (e.g pushState), all links have to be invalidated. This means walking the list of all potential links, and if that means all MathML elements that can be a performance issue. There are some things that can be done to optimize this, but they're fragile and complicated.

I can confirm this. For example in chromium:
// Base URL change changes any relative visited links.
// FIXME: There are other URLs in the tree that would need to be
// re-evaluated on dynamic base URL change. Style should be invalidated too.
for (HTMLAnchorElement& anchor :
Traversal::StartsAfter(*this))
anchor.InvalidateCachedVisitedLinkHash();

Note that this does not take into account MathML at all.

[NSoiffer]

As per the core meeting today, I am removing the 'need resolution' and 'tests' tags and adding 'level 2'. I have not checked to see if the spec needs updating.

[NSoiffer]

Removed 'needs spec update' because core doesn't mention links and hence, there is nothing to say/update. That's all saved for core level 2