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.

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.

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

* 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.

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?

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.

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

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

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?

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.

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..

• They have a default .tabindex of 0, even if you don't supply an href - but you can't actually sequentially focus them unless they do.
• They also mixin HTMLHyperlinkElementUtils... we aren't doing that
• They support a bunch more attributes that inform stuff about how to follow the link target, download, ping, hreflang, type, referrerpolicy and rel with all of the relevant hyperlink annotations: noreferrer, noopener, nofollow, etc and contain IDL props for some of these things that aren't in a mixin
• they affect selector matching for several CSS pseudo classes - at least some of those have some additional challenges -- :focus-visible for example treats some kinds of elements a little specially and doesn't draw a focus ring on them when they are clicked.. links is one of those. In some places (maybe all now) I think they might not actually get focused even.
• They're never going to be able to (themselves) have a shadow dom probably.

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:

• How important is it that core (v1) provides an answer to this question that is 100% backward compatible with existing content without a little JavaScript?
• Thusfar, core has been only 'subset' and 'explain existing stuff' - we've not added new things. Would we be ok with something that broke with that for linking? (ie, add a proper MathML a for consistency in the platform and simplicity in tying it all together).. This would render by default as mrow and I don't think causes any new sorts of problems but obviously there's not existing content like this, and I'm unsure how it would affect an old system?

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).

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..

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.

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.

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:

• Not having href is legal.
• The spec also says setting of the focus flag is suggested for 'a' with href and in Example 5 in this part of the spec about being focusable, it says 'sometimes <a href=""> (depending on platform conventions)' as one of the focusable nodes.

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...

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.

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.

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! :>

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)?

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.

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

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.

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.

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

• Firefox: Is link already, is in the right namespace, doesn't mess up the namespace of children, looks like math.
• Chrome: Is link already, is in the right namespace, doesn't mess up the namespace of children, looks like math.
• Safari: Is link already, is in the right namespace, doesn't mess up the namespace of children, looks like math (doesn't display).

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

I think the main benefits of a are:

• existing sanitizers that look for a href=javascript: but are MathML-unaware will remove href as intended
• the element name stands out more as being a link
• consistent with HTML and SVG

The benefits of mrow:

• the link works today in WebKit
• existing content with mrow href continues to work

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.

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.

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.

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.

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)?

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:

• Firefox: displays properly, linking works.
• Chrome: displays properly, linking works.
• Safari: displays properly, linking works

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>:

• Works: MS Word (native)
• Does not work: (generates an error): MathType, Mathematica, MathPlayer, MathCAT, JAWS

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).

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:

• Firefox: displays properly, linking works.
• Chrome: displays properly, linking works.
• Safari: displays properly, linking works

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>:

• Works: MS Word (native), JAWS (legacy math)
• Does not work: (generates an error): MathType, Mathematica, MathPlayer, MathCAT

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).

@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.

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

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?

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.

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

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.

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

Could MathML Core both:

• specify officially <a href> as the only link carrier
• specify fallback behavior for <mrow href> where instead of ignoring the attribute the <mrow> is treated as <a>.

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

@dginev that's not a middle ground, that's "why not both". I think we shouldn't support both, that seems more confusing and it doesn't address the XSS issue.

@zcorpan Endorsing both <a> and <area> hrefs in HTML is "why not both", my suggestion is very carefully not that.

Also, what XSS issue? Simply reading through the link you shared <a href> is also a known exploit, it doesn't really explain the concern.

@zcorpan Endorsing both <a> and <area> hrefs in HTML is "why not both", my suggestion is very carefully not that.

Your suggestion was to support href on both MathML a and mrow, yes?

Also, what XSS issue? Simply reading through the link you shared <a href> is also a known exploit, it doesn't really explain the concern.

The concern is that some existing sanitizers, if configured to allow mrow with href, will allow any value and thus allow javascript:something() as the URL. Whereas, if the element name is a instead, javascript: is checked and sanitized.

Your suggestion was to support href on both MathML a and mrow, yes?

No, it's very carefully not that.

It's to degrade <mrow href> to <a href>, which would then be the only official carrier of href in MathML.

A conforming sanitizer would then degrade <mrow href> to <a href> as well and use its usual <a> sanitization rules.

Maybe that's not possible, which is fine, but it is a different idea to officially endorsing both a and mrow.

I don't know what you mean by "degrade". Are you suggesting to change the HTML parser to change mrow to a if there's an href attribute?

I see a thumbs up.

Changing the HTML parser to change mrow to a is a non-starter. It can break assumptions and I see no benefit.

I think we need to decide between mrow or a as the MathML link element. Either is possible as far as I can tell, with different tradeoffs.