search

w3c / mathml-core

MathML Core draft
https://w3c.github.io/mathml-core
38 stars 14 forks source link

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

Open emilio opened 5 years ago

emilio commented 5 years ago

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:

davidcarlisle commented 5 years ago

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 commented 5 years ago

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 https://github.com/mathml-refresh/mathml/issues/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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 commented 5 years ago 
* 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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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

Technically:

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 commented 4 years ago

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

NSoiffer commented 4 years ago

The current discussion on w3c/mathml-core#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 commented 4 years ago

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.

bkardell commented 4 years ago

Links have all kinds of specialness, so it seems there's a lot of questions that wind up tying into this... The 'linky things that support href' (a in both HTML and SVG and area in HTML) have a lot more 'stuff' there..

There's a bunch of other tendrils here too I guess - they affect pushState, etc, etc - but all of these things are very user facing and at least seem that they need called out or answered at a spec level more.

So, I think there's two fundamental questions here that go to the aims of this initial work:

fred-wang commented 4 years ago

My personal opinion is that ability to link any subset of MathML formulas is an interesting feature. I'm not sure it is as fundamental as other things we are working on though. So I'd be happy to either ignore links for now (with some clever polyfill) OR introduce a new backward-incompatible <a> that is clean & consistent with HTML/SVG (this would give a straightforward DOM-converter polyfill).

bkardell commented 4 years ago

I have created a relevant pull request for the specification based on our conversation last week - however, in discussing with @fred-wang I think that we agree we'd like to discuss whether it might be a good choice/compromise to make this for token elements natively (most existing content) and think about adding an <a href> style thing for other uses... It would be good to make a decision because there are a number of things that follow this decision I think..

davidcarlisle commented 4 years ago

Wouldn't the new <a> just be (the existing) <mrow>? For the mathml language design, <a> seems slightly strange as all similar mathml elements start with m which is a concern, but mainly duplicating mrow seems to be adding complication.

Given how hard you're pushing for this, and re-raising it, I feel I must be missing something?

What does not allowing href on mrow give you? (given that content authors could simply use <a> everywhere where they currently use <mrow> whether or not an href is needed).

From compatibility and language design points of view, adding <a> seem somewhat unfortunate, but as I say above somewhere, if it helps smooth implementations I don't actually object to it, as smoothing implementations is more or less the point of mathml core. But (if only for my own education) it would be good to understand what the benefits are.

NSoiffer commented 4 years ago

Resolved: all leaf elements and mrow should support href and it's related properties; no other element should. Rob will review IDL change to support this that Brian created.

Need to write some tests. Brian submitted changes to the core spec.

NSoiffer commented 4 years ago

As per the MathML core meeting on 2/320, I was tasked to look into some accessibility issues related to href not being present on an element that can have it. The issue that @bkardell raised is that tabindex=0 when there is not href, but it is not focusable.

I asked a colleague who is very knowledgeable about accessibility and he said he was sure that was not legal. That caused me to look things up and indeed it is legal:

I tried out the following example in Chrome and Firefox (I know, it could have been written better): 

<h2> a link test </h2>
<p>
<a id="href" href="#a-nohref"> Standard anchor</a>.
<span id="value-href"></span>.
</p>
<p>
<a id="a-nohref"> An anchor, but not linked </a>.
<span id="value"></span>.
</p>
<p>
Here is some stuff outside of 'a'.
</p>
<p>
Here is some math with a link:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi id="mi-nohref">x</mi>
</math>
<span id="valueMathNoRef"></span>.
</p>
<p>
Here is some math with a link:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mi id="mi" href="#a-nohref">x</mi>
</math>
<span id="valueMath"></span>.
</p>
<script>
document.getElementById("value-href").textContent =
    ' tabindex=' + document.getElementById("href").tabIndex +
    ', focus=' + document.getElementById("href").focus;
document.getElementById("value").textContent =
    ' tabindex=' + document.getElementById("a-nohref").tabIndex +
    ', focus=' + document.getElementById("a-nohref").focus;
document.getElementById("valueMathNoRef").textContent =
    ' tabindex=' + document.getElementById("mi-nohref").tabIndex +
    ', focus=' + document.getElementById("mi-nohref").focus;
document.getElementById("valueMath").textContent =
    ' tabindex=' + document.getElementById("mi").tabIndex +
    ', focus=' + document.getElementById("mi").focus;
</script>

The results are the same in Chrome and Firefox for the a element. In Firefox, for the math/mi you get tabindex=-1 without the href; you get '0' when it is present. However, there is an accessibility warning that no action is associated with it despite the fact that clicking on it does change the focus appropriately. I suspect Brian is saying to himself "that's why we should inherit working code" :-)

I was a bit surprised that NVDA worked as I would want when there is no href (i.e., tabbing would not stop there). I think all screen readers will work the same. In both Firefox and Chrome, the accessibility tree does not show focus in those cases (there is no tabindex in the tree, just is the node focusable or not). So apparently some group (ARIA?) specified the behavior so that AT works well. However, I don't see it in API Mappings 1.1. In fact, that spec says

Where tabindex="0", set the focusable state and include it in the sequential tab order.

Not sure what is going on since that is not what Firefox and Chrome do. Seems like the implementations do the right thing (and hence inheriting their behavior is good) and that the mapping spec needs a bug fix...

faceless2 commented 4 years ago

I was about to post a new issue on this, but actually it ties in here.

Re. Brian's comment above about links having "all kinds of specialness" - a special aspect they need but that no-one has listed yet is alternative text to describe the link purpose in order to meet accessibility criteria (ref).

The "alt" attribute in HTML covers this, but there isn't - yet - an equivalent for general MathML elements, just the "alttext" on the root <math> element.

I'm not a WCAG expert so while it seems clear to me that some sort of "alt" attribute is required, I'm prepared to be corrected on this. But we're outputting MathML to PDF and I'm much more familiar with the equivalent specifications there (chiefly ISO14289). This requires alternative text on all links, not just those where the "purpose of each link can be determined from the link text alone" (as described in WCAG). So to meet this criteria, some sort of "alt" attribute is essential.

NSoiffer commented 4 years ago

Your point about "alt" and accessibility is a good one. In general, it isn't needed because links on MathML elements would normally have an obvious purpose (a definition or clarification of the symbol/notation) and therefore would meet the accessibility criteria. However, it is possible that someone might use them for some other reason, so it makes sense to allow for "alt" to be used on the MathML elements that accept "alt".

I'm on the 14289 committee and will suggest amending the text of 14289-2 to be consistent with WCAG. Thanks for pointing that out! Unfortunately that doesn't help you now as 14289-2 is still a work in progress.

fred-wang commented 9 months ago

I think we have several issues opened for href, but commenting on this one... Links were not integrated in level 1, so I'm marking existing tests as "tentative" in https://github.com/web-platform-tests/wpt/pull/44391

zcorpan commented 7 months ago

That this was overlooked in https://github.com/WICG/sanitizer-api/issues/168 suggests that supporting MathML links could possibly be used to exploit other sanitizers as well.

It's possible to use HTML a in MathML mi, mo, mn, ms, mtext. Is that sufficient?

I see comments that mrow links would be nice, but, even HTML doesn't support links for e.g. tr.

davidcarlisle commented 7 months ago

@zcorpan

It's possible to use HTML a in MathML mi, mo, mn, ms, mtext. Is that sufficient?

It's a very restricted subset of the mathml3 links as implemented in firefox, it's a useful subset and what could be achieved in mathml-core level 1 but a less restrictive subset would be good.

even HTML doesn't support links for e.g. tr.

That's not really a good comparison,

in html you can use <a href="#">one and two</a> but to make a link from mathml

<mrow><mn>1</mn><mo>+</mo><mn>2</mn></mrow>

you can only add <a> in token elements so three separate links

<mrow><mn><a href="#">1</a></mn><mo><a href="#">+</a></mo><mn><a href="#">2</a></mn></mrow>

or nest math in text in math

<math display="block"><mtext><a href="#"><math><mi>a</mi><mo>+</mo><mi>b</mi></math></a></mtext></math>

which is clearly less desirable both in markup complexity and (for the first) visible outcome of three links compared to the mathml3

<mrow href="#"><mn>1</mn><mo>+</mo><mn>2</mn></mrow>

accepted that allowing href on everything is probably never going to fly but allowing it just on mrow or having a separate <mlink or <ma that acts like <mrow> for layout but like <a for linking would still be a valuable addition.

So if it's too difficult to add more linking, people will cope, but "sufficient" isn't the word I'd use to describe the current restrictions.

dginev commented 7 months ago

I see comments that mrow links would be nice, but, even HTML doesn't support links for e.g. tr.

For inline expressions mrow is somewhat analogous to a span, often collecting together adjacent argument nodes for an operator. More recently it is increasingly popular as a wrapper for holding class and style attributes, so much so that we have a deprecation suggestion for the more traditional mstyle in #181 .

The tr analog in MathML is mtr. Choosing names is hard.

When I imagine mrow with an a, as in:

<mrow class="number-set">
  <a href="https://simple.wikipedia.org/wiki/Positive_number">
    <msub>
      <mi>ℤ</mi>
      <mo>+</mo>
    </msub>
  </a>
</mrow>

to me it would be just as natural as span with an a in HTML, as in:

<span class="number-set">
  <a href="https://simple.wikipedia.org/wiki/Positive_number">
    ℤ<sub>+</sub>
  </a>
</span>
annevk commented 7 months ago

This feature currently doesn't work in Chromium and is quite broken in WebKit.

I'd almost be more in favor of figuring out if we can change the HTML parser to allow HTML <a> inside MathML somehow than to continue to support this.

davidcarlisle commented 7 months ago

I think it's generally recognised that allowing href everywhere isn't going to work. But having one element that works like mrow (or html span) for layout but allows href linking would be really good.

That could be done by any of:

I have some personal preferences between those but whatever is most implementable and best fits with other web platform constraints would be fine

fred-wang commented 7 months ago

In previous discussions, I stated that my preference was to support href on only a single MathML element behaving like an <mrow>. Probably just a new <a> in the MathML namespace (similar to what exists for SVG).

For the record, href has not been implemented in the initial MathML release in Chromium (even if we had a patch for that) and it was removed from MathML Core L1 because we were not able to reach a consensus in the mentioned discussions .

brucemiller commented 7 months ago

I like @davidcarlisle 's first suggestion: Simply allowing linking from mrow itself (and only mrow), rather than introducing any new element or further mixing html & mathml (eg embedding a).

This would minimize the pain of a transition period since as generators & browsers evolve their support, the worst breakage would be whether or not an href was clickable. That would be easy to live with; the breakage in other cases (esp. when the html parser starts getting creative) could be pretty bad.

mrow is the new mstyle! :>

bkardell commented 7 months ago

This feature currently doesn't work in Chromium and is quite broken in WebKit.

I'd almost be more in favor of figuring out if we can change the HTML parser to allow HTML <a> inside MathML somehow than to continue to support this.

This sounds great to me if it's possible, probably! Best way to align things in my mind. I guess the biggest question is is it possible? Would all of the vendors definitely be open to it (hesitation to break/change content by some is part of what led to dropping it from L1)?

brucemiller commented 7 months ago 
I'd almost be more in favor of figuring out if we can change the
HTML parser to allow HTML |<a>| inside MathML somehow than to
continue to support this.

My concern here is that the transition period will be quite painful. The html parser of an unpatched browser that sees an a in an unexpected place (except within a token?), will convert the tree into something rather unexpected, and probably very un-math-like.

zcorpan commented 7 months ago

That this was overlooked in WICG/sanitizer-api#168 suggests that supporting MathML links could possibly be used to exploit other sanitizers as well.

I tried to find any existence proof of this. https://github.com/cure53/DOMPurify and https://github.com/rhukster/dom-sanitizer allow MathML elements but seem to remove href="javascript:" regardless of element and namespace. Still, there could be weaker sanitizers that only look for href on a/area tags.

For @annevk 's idea to change the parser, I think that may be worse from an XSS risk perspective. There are various sanitizer bypasses involving SVG or MathML. Inserting an HTML element but still being in foreign content (to be able to insert MathML elements) could break expectations. I think we shouldn't go this path.

Adding an a element in the MathML namespace would work fine as far as current HTML parsing goes (demo). Since SVG already has a separate element, if we want to share features between HTML a and SVG a then also sharing with a MathML element should be possible.

bkardell commented 7 months ago

fwiw, I didn't realize that <a> had no parser fixup and this it just becomes an unknown element in the MathML namespace. Nice. That's even more ideal to me :)

@brucemiller maybe, but we have already defined unknown elements should render as mrows

Unknown MathML elements behave the same as the mrow element.

(https://w3c.github.io/mathml-core/#new-display-math-value)

so is it really very different than just allowing href on an mrow? Also, no content today would have that, so it's not like existing content is going to break this way. I suppose the one thing that won't happen is that existing mrow links won't Just Work

davidcarlisle commented 7 months ago

so is it really very different than just allowing href on an mrow?

href on mrow is clearly more consistent with the overall mathml design and is compatible with mathml3 and has been implemented in firefox for a decade or so.

So I suspect anyone coming to this "from mathml" is going to prefer that option.

That said, it seems that people coming to this from general web platform standpoint have a preference for re-purposing a

so I'd prefer href on mrow, but I'd be happy to get the functionality with any syntax that works.

fred-wang commented 7 months ago

fwiw, I didn't realize that <a> had no parser fixup and this it just becomes an unknown element in the MathML namespace. Nice. That's even more ideal to me :)

@brucemiller maybe, but we have already defined unknown elements should render as mrows

Right, so considering only MathML Core, if we add some parser fixup to make sure <a> in MathML is inside the HTML namespace as that was suggested above, then that leads to a not-yet-defined behavior (see #57) ; currently WebKit and Chromium will just not render anything while Firefox will render something that probably does not behave as an mrow (missing all the operator spacing, stretching and all).

If we introduce a new <a> element in the MathML namespace instead, then the behavior described in the spec will be unchanged (layout remains equivalent to mrow) and we will just introduce a new link-related behavior for the <a> element ; and all the security restriction need to apply to that element only.

Of course the concern here is that not all existing implementations or documents align with MathML Core. I believe having <mrow> as the unique linkable element could be ok to reduce compat concerns. However, that could also make more difficult future extensions with shadow root and custom elements (#69 #138) as IIRC there is some text in another spec excluding linkable elements for such use cases.

bkardell commented 7 months ago

No but it doesn't need a parser fixup, it just needs to be defined in MathML-Core equivalently... and I think mainly beyond that it's just a matter of making it work like the rest of the spec says already, right?

https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=12512

zcorpan commented 7 months ago

Right, no parser changes necessary with a in the MathML namespace.

I think the main benefits of a are:

The benefits of mrow:

davidcarlisle commented 7 months ago

I think adding <a> to mathml is workable, specifically

<!DOCTYPE html>
<html>

 <body>

  <math display="block"><mi>x</mi> <mo>+</mo> <a href="https://www.w3.org"><mi>a</mi><mo>+</mo><mi>b</mi></a></math>

 </body>
</html>

which currently displays correctly (ie a acting as mrow in chrome and firefox, and the link works in firefox) the "consistent with html and mathml" argument certainly has a lot of weight in this context.

losing this:

existing content with mrow href continues to work

is a bit of a pain except (a) it's already lost for content designed to work in mathml-core level 1 and (b) it's hardly the only feature of mathml 3 that doesn't survive and will need a polyfil or document changes.

annevk commented 7 months ago

FWIW, I think keeping mrow as sole linking element is fine. It doesn't seem like it really results in overloading if that element is essentially a span. The name is a bit weird, but it's hardly unique in that.

bkardell commented 7 months ago

The link is the most important element in the web, it would be really nice if there were a commonly recognizable way to link across HTML, SVG and MathML imo. I don't think it is the end of the world if we choose to make mrow the one linkable element instead, but it feels like an unfortunate missed opportunity to me to make MathML not the weird outlier - especially given the points above.

dginev commented 7 months ago

Curious dilemma, I wasn't expecting we would have two viable paths forward.

Based on the Math WG discussion yesterday (March 28), we were unanimous that from a MathML perspective the better solution is in <mrow href="#">. It allows for the tree to be kept a little more compact, and keeps existing code for traversing and manipulating MathML free of surprises. But we also agreed that adding <a> is workable for everyone as an alternative solution (and is vastly preferable to no support for hyperlinks).

Are there any trade-offs to keep in mind? Is it easier to interoperate with other mechanisms, such as <base> or the original topic of this issue - the CSS :visited selector? I see that currently :visited is only usable over <a> and <area> - would it need a dedicated extension for <mrow href="#">? I suspect this question also applies for :link and :active.

zcorpan commented 7 months ago

It allows for the tree to be kept a little more compact

I think this is not the case; if you swap an existing mrow for a there's no change to the number of elements in the tree.

<base> and :visited should be equivalent in implementation.

@fred-wang

I believe having <mrow> as the unique linkable element could be ok to reduce compat concerns. However, that could also make more difficult future extensions with shadow root and custom elements (#69 #138) as IIRC there is some text in another spec excluding linkable elements for such use cases.

Yes, HTML a does not allow attachShadow. https://dom.spec.whatwg.org/#valid-shadow-host-name only lists HTML elements without a default action or special behavior. So maybe this is the tiebreaker: should mrow support attachShadow (like HTML span)?

NSoiffer commented 7 months ago

I am one of those that was in the Math WG meeting that agrees getting linking is better than not having any linking. But for backwards compatibility, I strongly prefer leaving it on mrow.

To copy @bkardell's list, this time for href on mrow:

So the only browser where a link on mrow does not work now is Chrome.

MathML is used in applications beyond the browsers. I doubt many of those applications do anything with links, but many of them aren't happy when they encounter tags that aren't part of MathML 3. As a test, here are the applications I tried using <a>:

MathPlayer and MathCAT are apps/addons to the NVDA screen reader for reading math. MathPlayer has been EOL'd and can't be changed. MathCAT is the replacement I'm writing, so it can be changed. JAWS has started to use MathCAT as its math speech tool, but currently choosing between legacy JAWS math and MathCAT is an option.

If supporting legacy documents and applications is important, there is a compelling case to allow href on mrow. That's particularly true given how slow browser compatibility of MathML core implementations is moving forward :-((

If that's not an option, then adding <a> to core and making sure it is also added to Firefox and Safari in a timely manner is next best. What is really bad is having the situation which we have at the moment where some things work in Chrome and other things work in FireFox and Safari (e.g., CSS support for features that are supposed to take the place of MathML 3 elements/attrs).

NSoiffer commented 7 months ago

I am one of those that was in the Math WG meeting that agrees getting linking is better than not having any linking. But for backwards compatibility, I strongly prefer leaving it on mrow.

To copy @bkardell's list, this time for href on mrow:

So the only browser where a link on mrow does not work now is Chrome.

MathML is used in applications beyond the browsers. I doubt many of those applications do anything with links, but many of them aren't happy when they encounter tags that aren't part of MathML 3. As a test, here are the applications I tried using <a>:

MathPlayer and MathCAT are apps/addons to the NVDA screen reader for reading math. MathPlayer has been EOL'd and can't be changed. MathCAT is the replacement I'm writing, so it can be changed. JAWS has started to use MathCAT as its math speech tool, but currently choosing between legacy JAWS math and MathCAT is an option.

If supporting legacy documents and applications is important, there is a compelling case to allow href on mrow. That's particularly true given how slow browser compatibility of MathML core implementations is moving forward :-((

If that's not an option, then adding <a> to core and making sure it is also added to Firefox and Safari in a timely manner is next best. What is really bad is having the situation which we have at the moment where some things work in Chrome and other things work in FireFox and Safari (e.g., CSS support for features that are supposed to take the place of MathML 3 elements/attrs).

dginev commented 7 months ago

@zcorpan

So maybe this is the tiebreaker: should mrow support attachShadow (like HTML span)?

It probably should (like HTML span), as the use cases are similar. This may be a compelling reason to introduce <a>.

Btw this is also why we can't assume <a> will generally replace an <mrow> keeping the tree size the same - if you needed to attach a shadow root, I suspect we have to go for <mrow><a href> combination, as with <span><a href>.

And for generator tools which don't know in advance when shadows would be desirable, the default choice would be to generate both. Which is fine.

annevk commented 7 months ago

It's not clear to me the current safelist for attachShadow() is useful precedent. Existing content seems like a more important factor.

bkardell commented 7 months ago

The a11y tools related one is potentially the strongest argument in my mind.

It really sounds like people seem to be converging on <mrow> - I'll just make one effort to explain why the other points don't actually seem super strong to me..

Most use of href in existing content is not on mrow, but tokens. So if we choose <mrow> then most existing links still don't work. Sure, it can be transformed to wrap with whatever the linking element is, but in that case, which specific element doesn't actually matter

So the only browser where a link on mrow does not work now is Chrome.

Only by some very lose definition of "works" though, it's not actually that much more than a (the point of my list was just to illustrate parse/render concerns were largely unfounded). Currently where it is supported it still it doesn't support any of the important attributes or match link styles appropriately, or have similar default tabindexes, etc. We still have to actually do all of those things.

I guess my personal preference, if we have to admit all of the above would be to add support in a way that makes MathML less weird and unique. We have stated that we want to get to a future in which new things 'lift all boats' - when we add ideas like shadow doms and popovers it's not an impossible discussion about if/how this relates to MathML (or SVG) because we're talking about largely "one platform"... It seems to me inevitable (given what we've already dealt with) that weird, unique legacy things have future impacts. Again, admitting all of the things above, it seems to me the future is longer than the past.

That said, the a11y tools is very strong. I'm not sure how difficult or impractical it is to change MathType/Mathematica, but I also assume that this is again going to be the case if/when we eventually add any new element, too? @NSoiffer do you know?

brucemiller commented 7 months ago 
So the only browser where a link on mrow does not work now is Chrome.

Only by some very lose definition of "works" though, it's not actually that much more than a (the point of my list was just to illustrate parse/render concerns were largely unfounded). Currently where it is supported it still it doesn't support any of the important attributes https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attributes or match link styles appropriately, or have similar default tabindexes, etc. We still have to actually do all of those things.

I'm confused; I would have thought that that "a" within math disappearing completely in Safari was exactly a well-founded concern.

It at least means that with the a-enhanced route, some user agents will display new material wrong; you would have to serve different formats to different browsers and/or use polyfills. That's not to say tha this is the single most important decision point (we've dealt with worse), but it shouldn't be dismissed.

In contrast, the mrow-enhanced route tends to fail more gracefully: new content will still look like math, but may or may not support any or all href-related attributes, depending on the browser. That's basically the status-quo, but with a path forward. [Noting that there are several layers of work/don't work being discussed here: all href attributes supported; just basic href attributes supported; no href supported versus doesn't even look like math]

I'm sympathetic to your goal of making MathML less "odd", but it's hard for me to judge how significant the difference between adopting an "a" versus mrow with href would be. I'm perhaps too cynical (w/reason) to think that MathML will suddenly be BFF, but you may be correct that adopting a would smooth future evolutions?

bkardell commented 7 months ago

I'm confused; I would have thought that that "a" within math disappearing completely in Safari was exactly a well-founded concern.

I said "largely" :). It is limited to 1 bug in 1 engine (note it is a bug that needs fixing no matter what we decide here). There is currently no MathML content uses <a> there and I expect authors would simply wait until we fixed that bug to start using it. I'm not arguing the <mrow> version has a slightly smoother path in the very short term, I just really do think it is only slightly, for a brief window of time.

But again, the a11y tools one is a strong argument.

zcorpan commented 7 months ago

While searching GitHub for "mrow href" I found that it's a known XSS exploit, which indicates that it is being (or at least has been) used to bypass HTML sanitization:

https://github.com/xsscx/Commodity-Injection-Signatures/blob/5ef14a430ba6140112e40376c036bf66809861c5/no-experience-required-xss-signatures-only-fools-dont-use.txt#L717

fred-wang commented 7 months ago

Just for the record, https://w3c.github.io/mathml-core/#security-considerations has some description of known sec issues with MathML 3 including the case of maction + href (see also https://bugzilla.mozilla.org/show_bug.cgi?id=1392258 ). If we add back href into MathML Core, we shouldn't forget to update this section accordingly.

dginev commented 7 months ago

I have a middle ground idea, but I am unsure if it is feasible from an implementation perspective.

Could MathML Core both:

This could address the backwards compatibility question for existing docs, while also starting on the path to web platform uniformity.