[interest invokers] Should we support other forms of link elements?

[lukewarlow]

Currently HTMLAnchorElement, HTMLAreaElement, HTMLInputElement (when in button form), and HTMLButtonElement.

Now for the deep breath.

You'll notice these are all HTML elements.

However, there are anchor elements in other namespace(s).

Should we also support SVGAElement (lovely naming consistency) as an interest invoker? It behaves much the same way as HTMLAnchorElement.

[lukewarlow]

The story with MathML and href is much more complicated as @bkardell can attest to, but there's discussions about standardising a MathML <a> element too, so any decision here would also apply to that (or whatever element MathML ends up with for links it might be <mrow>).

[lukewarlow]

Fwiw I implemented it for SVGAElement in chromium locally and it's a trivial change. I made sure to anchor everything to Element not HTMLElement when implementing initially, so it just basically just works.

So I can't see a compelling case against just supporting them?

[mfreed7]

Feels like "link-like things" should be supported, if we're supporting <a>. So makes sense to me, especially if the implementation didn't pose any issues.

[css-meeting-bot]

The Open UI Community Group just discussed [interest invokers] Should we support other forms of link elements?, and agreed to the following:

• RESOLVED: Support interest invokers on link like elements, specifically SVGAElement.

The full IRC log of that discussion

<masonf> q+
<keithamus> luke: Prototype interest invokers. Realised we handle html anchor element, but not svg "a" element. Feels like we should? invokers are on Element making it easy to impl for other namespaces.
<keithamus> Given that I don't see a reason to not support SVG a, as well as other namespaces like mathml
<keithamus> masonf: +1. Links, not particular elements, svg a is a link - we should support unless we run into architectural issues
<masonf> ack mason
<brecht_dr> +1
<keithamus> keithamus: what about interactive elements in general?
<keithamus> luke: we might want to defer inputs/selects for now
<bkardell_> +1 to luke's proposal and mason's comments
<keithamus> masonf: intention is to support as many as we can until we run into roadblocks
<bkardell_> and also mathml should have an <a>
<keithamus> luke: as many elements that are hoverable/focusable as possible. Previously Scott raised about keeping the number of elements lower initially.
<keithamus> luke: if we support links they should be in all their forms, with the intention to support elements in future. Only questions: this is planned to be in HTML spec.
<keithamus> luke: maybe we just update SVG spec to introduce it?
<keithamus> luke: only other aspect is svg link elements with href announced to at? If so great, if not maybe we don't want to encourage usage.
<masonf> q?
<keithamus> masonf: generally agree. Support as much as possible including all the a11y stuff. Part of HTML spec would be to support the IDL on element, but that's minor.
<scotto> q+
<bkardell_> q+
<keithamus> luke: firefox lets you put href on all mathml elements and it works, chrome doesn't webkit some does some doesn't.
<keithamus> luke: mathml core doesn't specify
<keithamus> q?
<masonf> ack scott
<luke> Proposed Resolution: Support interest invokers on link like elements, specifically SVGAElement.
<keithamus> scotto: there are a number of specs essentially addons to HTML. svg, mathml, dpub, dpub aria uses html to write content. Other specs with markup language, repeat elements defined in html for their own purposes for e.g links. Does this apply to those as well? Just SVG? Is A in SVG defined in svg? Or is it how html references these in DOM?
<keithamus> scotto: part of what should be investigated is does every spec need to be updated? Is SVG just HTML a?
<keithamus> luke: SVG a is defined in SVG spec.
<masonf> Spec: https://svgwg.org/svg2-draft/linking.html#Links
<keithamus> luke: both HTML a, area, and SVG a use html hyperlink utils. Any link-like element should use the mixin and get it for free.
<keithamus> luke: namespacing might be difficult but we can spec it out
<keithamus> masonf: we should focus this on; is this a good thing to do then we can focus on spec/impl
<keithamus> scotto: yeah. I want to keep list small, but hyperlink in svg/html then that sounds good
<masonf> ack kardell
<masonf> ack bkardell
<keithamus> bkardell_: mathml was first spec in w3c in 1998. Had the ability to put an href on anything. Its implementation in firefox is almost that. WebKit is almost that. That's not a good design though. When we went to do mathmlcore and into chromium, we hit this wall. No implementer was interested.
<keithamus> bkardell_: implementers are now interested due to this, sanitizer, etc. Mathml, as long as we can get people in a room, will get an answer to this question. None work the way they should.
<keithamus> bkardell_: you also cant do related attributes as part of mixin.
<keithamus> bkardell_: Anyway, +1 what luke said. That's why there isn't one specced. mathml 3 specs all of them but this won't be popular.
<keithamus> masonf: having it on any element means arbitrarily nested links?
<keithamus> bkardell_: html too
<masonf> q?
<keithamus> luke: use case for charts; tooltips on chart elements.
<keithamus> luke: that plus the fact it was easy enough.
<bkardell_> fwiw lots of educational math has tooltips for almost every part of an equation
<keithamus> masonf: desire to support any element? Having some way in svg to have tooltips sounds great. This being one of the first means we need to resolve the linking issues which is good to solve together
<keithamus> +1
<masonf> +1
<bkardell_> +1
<brecht_dr> +1
<luke> RESOLVED: Support interest invokers on link like elements, specifically SVGAElement.
<keithamus> Zakim, next issue
<Zakim> I don't understand 'next issue', keithamus
<bkardell_> resolved, scotto is excited
<scotto> lol