Align anchor IDL across the platform?

[bkardell]

What is the issue with the HTML Standard?

Given recent work on the Sanitizer API, SVG and MathML it seems like it would make sense to share as much as possible, as easily as possible about what it means to be a link..

Is it worth breaking out a generic anchor element and then keeping the downstream specs very simple? Maybe something like

[Exposed=Window]
interface AnchorElement : HTMLElement {
  [HTMLConstructor] constructor();

  [CEReactions, Reflect] attribute DOMString download;
  [CEReactions, Reflect] attribute USVString ping;
  [CEReactions, Reflect] attribute DOMString rel;
  [SameObject, PutForwards=value, Reflect="rel"] readonly attribute DOMTokenList relList;
  [CEReactions, Reflect] attribute DOMString hreflang;
  [CEReactions, Reflect] attribute DOMString type;

  [CEReactions] attribute DOMString text;

  [CEReactions] attribute DOMString referrerPolicy;

  // also has obsolete members
};
AnchorElement includes HTMLHyperlinkElementUtils;

and then

[Exposed=Window]
interface HTMLAnchorElement : AnchorElement {
  [CEReactions, Reflect] attribute DOMString target;
};

And in MathML...

[Exposed=Window]
interface MathMLMAElement : AnchorElement {
  [CEReactions, Reflect] attribute DOMString target;
};

And in SVG

[Exposed=Window]
interface SVGAElement : AnchorElement {
  [SameObject] readonly attribute SVGAnimatedString target;
};

[annevk]

I think it would be more logical to expand HTMLHyperlinkElementUtils further and reuse that everywhere. Introducing a new object in the prototype chain seems quite risky.

[lukewarlow]

I think it would be more logical to expand HTMLHyperlinkElementUtils further and reuse that everywhere. Introducing a new object in the prototype chain seems quite risky.

To do that we specifically have to remove href from that mixin as it conflicts with SVG.

[annevk]

That seems okay.

[lukewarlow]

Looking at this more href is quite tightly embedded into the other properties of that mixin. Now I can envisage this becoming a HyperlinkElementUtils with some algorithms left to the implementing type. Like https://html.spec.whatwg.org/multipage/links.html#concept-hyperlink-url-set and https://html.spec.whatwg.org/multipage/links.html#update-href I think we could make it so they're implemented in the concrete types and implement an SVG specific version of them. However, I'm not sure what the SVG specific version would be, I guess we'd need to define something ahout looking for xlink:href too? and no browser actually implements this mixin for SVG (despite the spec).

Is this mixin really the best place for us to start with this? Or should we make a new one that shares stuff such as hreflang and download that can be used by SVG and MathML?

[lukewarlow]

As an initial attempt at making progress I've made #12066, this does the initial refactoring to make this mixin (well technically a new one) work for SVG <a> too.

Once we have this HyperlinkElementUtils mixin we should be able to move more of the shared stuff to it. That way SVG, HTML and MathML can all share a definition.