Should all MathML elements really be potential hyperlinks / match :visited?

[emilio]

https://mathml-refresh.github.io/mathml/#attributes-shared-by-all-mathml-elements says:

href: Can be used to establish the element as a hyperlink to the specfied URI.

This in Gecko has implications and behaves the same way as <a> or <area>.

Two things:

• Is this feature used / desired / worth it? Links are complex.

• If it is, should it really match :visited? I think in WebKit it does not, if I'm reading the code correctly.

[davidcarlisle]

certainly the linking is used and worth keeping, in practice they are almost always used with token elements so if that would simplify the implementation could consider restricting href to token elements in core at least.

[fred-wang]

Yes, href is necessary otherwise you can't create a link for a subformula, only the whole formula. MathML3 basically allows it on all elements and it was a replacement for the xlink::href attributes: https://www.w3.org/TR/MathML3/chapter6.html#interf.link

We have some stats in w3c/mathml#55 although we didn't ask this explicitly, probably we should?

For consistency with HTML and SVG, I guess it makes sense to restrict it to only a container element (rather than to all MathML elements), which would be <mrow>. Any element can be wrapped in such an <mrow> if it's necessary to create a link.

[davidcarlisle]

forcing it on mrow would make the mathml a lot more verbose than it already is (in our mathml for example almost every mi is a link) allowing href on all (or most) elements was explicitly raised with whatwg at the time of the mathml integration and the feedback we had at the time was that (as far people were interested in implementing mathml at all) the href attribute wouldn't be a problem.
if it was mrow and token elements (mi,mn,mtext,ms) then that would cover all proactical cases

[NSoiffer]

I have all elements, although math, mrow, and leaf elements is a reasonable compromise if it is hard to implement. For full, a polyfill could add an mrow in that case. Neil

…

On Sat, Aug 10, 2019 at 12:23 AM David Carlisle ***@***.***> wrote: forcing it on mrow would make the mathml a lot more verbose than it already is (in our mathml for example almost every mi is a link) allowing href on all (or most) elements was explicitly raised with whatwg at the time of the mathml integration and the feedback we had at the time was that (as far people were interested in implementing mathml at all) the href attribute wouldn't be a problem. if it was mrow and token elements (mi,mn,mtext,ms) then that would cover all proactical cases — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/mathml-refresh/mathml/issues/125?email_source=notifications&email_token=AALZM3F37RR4HI26VQICSALQDZUIHA5CNFSM4IKTJESKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4AH6WA#issuecomment-520126296>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALZM3HPHD4DYY6DKI5QYMTQDZUIHANCNFSM4IKTJESA> .

[fred-wang]

* If it is, should it really match `:visited`? I think in WebKit it does not, if I'm reading the code correctly.

For the record, Gecko has a test for this: https://searchfox.org/mozilla-central/source/layout/style/test/test_visited_reftests.html ; not sure how easy it is to write one with WPT.

[bkardell]

After a bunch of discussion at/driven by conversations at our hackfest, I believe (and I think @NSoiffer agrees) that we should limit this to token elements. I'm not entirely sure that I really understand the real need since <a href=""> should be legit content of any of the elements and I'm not sure I understand how there is a difference of substance, but I suppose the data seems to suggest that these are where this feature is really used, and that it's mostly (exclusively even?) token elements. Anyways, the reason is that links have activation behavior and a bunch of specific things that add complexity to the idea of adding something like shadow dom. I'm not suggesting that adding it will be trivial without or something, but it seems very unlikely to add such features in the near term if we just say that everything can be a link.

So, for simplicty sake, is there any objection to limiting it?

[davidcarlisle]

So, for simplicty sake, is there any objection to limiting it?

Not really, I have some mrow href... eg the 1..n link in

https://www.nag.co.uk/numeric/nl/nagdoc_27/flhtml/f08/f08upf.html#jfail

(which is native mathml rendering if you use firefox, mathjax otherwise)

but in the full collection there, there are 30 <mrow with href as opposed 97549 <mi and 3226 <mn, so dropping this is not a big issue for this set of documents and certainly if it causes you any extra implementation issues or difficult discussions with the browser makers then make it token elements only.

[fred-wang]

Note that there are existing content and tests using href on mrow.

Technically:

• limiting to mrow would still make all the other cases polyfillable (basically wrap the MathML element to link in an mrow) so it's not making MathML weaker.
• limiting to token elements, one won't be able to make a subset of a formula linkable. Which I believe can be an interesting use cases (e.g. link to a definition of a math notation).

We need to update https://html.spec.whatwg.org/#dom-tabindex to indicate which element should have tabindex 0. Currently, we only test mrow: https://w3c-test.org/mathml/relations/html5-tree/tabindex-001.html

[fred-wang]

See also https://github.com/mathml-refresh/mathml/issues/152#issuecomment-582680428

[NSoiffer]

The current discussion on #63 really belongs here, so I'm commenting on this issue in the hope the discussion returns to this issue...

There was some discussion about MathML should be like HTML/SVG. SVG does have a a element, but according to this MDN page, it also allows href on 15 elements (with various meanings/restrictions based on the element). That's a long way from "all" elements like the current MathML spec, but it is also a long way from just 4 leaf elements.

In https://github.com/mathml-refresh/mathml/issues/152#issuecomment-583440328, @bzbarsky wrote:

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 imagine anytime there is a link, there is a much that might need to be updated. What I'm unclear on is why the number of elements that might have a link is the issue as opposed to the number of links. It seems (from my naive point of view), you just need to find the elements that have a link (which in MathML is any element with an href attribute). Why would it make a difference if the number of elements with a potential href is 4 or 40? Can you clarify?

[bzbarsky]

it also allows href on 15 elements (with various meanings/restrictions based on the element)

Yes, but those don't act as "links", just like the src attribute on HTML's img does not act as a "link".

you just need to find the elements that have a link

This is the "There are some things that can be done to optimize this, but they're fragile and complicated" bit from that comment. Yes, you can do this, but maintaining that state is a pain and slows down various DOM mutations and whatnot.