Repository navigation
SVGAElement implements two conflicting interfaces #312
Description
The SVGAElement in the SVG 2 Linking chapter implements two interfaces where both two define their own href attribute:
SVGAElement implements SVGURIReference;
SVGAElement implements HTMLHyperlinkElementUtils;[NoInterfaceObject]
interface SVGURIReference {
[SameObject] readonly attribute SVGAnimatedString href;
};[NoInterfaceObject]
interface HTMLHyperlinkElementUtils {
stringifier attribute USVString href;
readonly attribute USVString origin;
attribute USVString protocol;
attribute USVString username;
attribute USVString password;
attribute USVString host;
attribute USVString hostname;
attribute USVString port;
attribute USVString pathname;
attribute USVString search;
attribute USVString hash;
};The spec does not say which definition should be followed, and I think this conflict shouldn't in the spec. Is this a problem can be fixed?
Activity
AmeliaBR commentedon Apr 8, 2017
The SVG one should take precedence; it needs to, for backwards compatibility with SVG 1.1.
But the IDL as written is definitely not clear about that. I'm not sure if there's an easy way in IDL to represent that sort of polymorphic inheritance. In other cases of a conflict (between an SVG 1.1 property and an interface with a same-named property), it's clear that the currently defined class member overrides the interface. But this is two different interfaces.
Either way, it's one more case of SVGAnimatedString being the bane of any attempts to harmonize SVG-DOM and HTML-DOM.
dstorey commentedon Apr 3, 2018
As the IDL is written currently the SVG one doesn't take precedence. I believe in is invalid WebIDL. Edge for sure breaks when trying to mixin a member that already exists.
The solution here, which will likely happen in the HTML spec is for href to be removed from HTMLHyperlinkElementUtils and put in its own mixin (as SVG) or directly on the interfaces it is used on. Once (or if) that change is made, we should be able to automatically close this one.
boggydigital commentedon Jun 11, 2018
Not blocking updated 2.0 CR publication - assigning 2.0 Recommendation milestone to clean this up before 2.0 REC
AmeliaBR commentedon Aug 13, 2018
Another Possible solution:
Have
SVGURIReferenceincludeHTMLHyperlinkUtils, so that it is clear which version has priority: the SVG definition overriding the inherited HTML definition. With the side effect that the hyperlink-decomposition properties (origin,hash, etc.) would be available on any SVG element with anhref(or oldxlink:href) attribute.AmeliaBR commentedon Aug 13, 2018
Hmm, don't think my previous comment is valid.
Looking at the WebIDL spec, mixins can be extended with partials, but cannot inherit from another mixin. And mixin members "describe the behaviors that can be implemented by an object, as if they were specified on the interface that includes them", not as if they were inherited into the object. So there's no option for overriding an inherited definition.
So:
Best solution is as @dstorey suggested, to ask HTML to decompose
HTMLHyperlinkUtilsto removehref.But, in the meantime, we should probably remove
HTMLHyperlinkUtilsfrom SVG anyway, since it doesn't appear to be implemented anywhere. See https://codepen.io/AmeliaBR/pen/1c0f6d1bb1cffa4799b6cf617f9efd41?editors=0011dstorey commentedon Aug 15, 2018
There is an issue in WHATWG HTML to change the HTMLHyperlinkUtils mixin so its definition is shared with HTML and SVG, but I haven't found the time to make a proposed PR yet.
AmeliaBR commentedon Jul 4, 2019
As reported in #709, this is causing problems with auto-generated tests: web-platform-tests/wpt#12231
We really need to figure out a way to define this.
Maybe define a non-exposed intermediary interface that uses the HTML mixin, then define an SVG interface that inherits from that and also mixes in the SVG definition of
href, which then clearly overrides the inherited HTML definition?lukebjerring commentedon Jul 4, 2019
@heycam - whatever the case for resolving this issue, IDL spec isn't super clear on what happens when things clash (i.e. doesn't explicitly state that it's not allowed, or what would take precedence). I did see a description of method overloading, but not plainly re-defining an attribute.
css-meeting-bot commentedon Jul 15, 2019
The SVG Working Group just discussed
SVGAElement implements two conflicting interfaces.The full IRC log of that discussion
<krit> topic: SVGAElement implements two conflicting interfaces<myles> GitHub: https://github.com//issues/312
<myles> AmeliaBR: We've discussed this before. We know how we want the spec to work for backwards compatibility needs, but we need a way to make it correctly defined in WebIDL. I put it on the agenda because we got a bug report that it was breaking some Web Platform tests that were trying to create automatic tests based on IDL and our IDL is broken.
<myles> AmeliaBR: We're using an HTML mixin which defines an href property, but we also have our own mixin that defines a different version of the href property. The SVG <a> element uses both of these mixins, and there's nothing in WebIDL that says which one should have priority. For backwards compatibility, the SVG version needs to have priority even though its less useful.
<myles> AmeliaBR: My suggestion is maybe we can somehow introduce a "dummy" interface just so that we can inherit from the dummy interface in a way that it makes it clear that the SVG href is overriding the HTML href. It's kind of an ugly way to do it, but it's an ugly situation. The important thing is the end result spec is clear about what should happen.
<myles> krit: The problem is that href is defined in two interface objects, and HTMLAElement implements both.
<myles> AmeliaBR: And WebIDL doesn't define which one wins.
<myles> AmeliaBR: But if you both inherit and override, then WebIDL does define which one wins.
<myles> AmeliaBR: So if we created some sort of interface that implements HTMLHyperlinkUtils, and inherit from that, and then override it ....? It's going to be ugly either way. The other way is to take this up with WebIDL and get it officially specified somewhere in IDL that if you have two mixins, there is a priority order. This is a cleaner solution.
<myles> AmeliaBR: It requires a dependency on another spec.
<myles> krit: Is it possible to inherit from a non-interface object?
<myles> AmeliaBR: I don't think so. That should be a mixin rather than an interface.
<myles> krit: righ.t
<myles> krit: Another alternative is we don't use HTMLInterfaceHyperlinkUtils
<myles> AmeliaBR: I don't think we have any implementations. I haven't tested
<myles> krit: What if we make a resolution depending on testing? We can make a resolution now, and then re-discuss if there is an implementation of HTMLHyperlinkUtils
<myles> AmeliaBR: That probably makes sense
<myles> AmeliaBR: If we don't have implementations, we can drop it. Though, one of the reasons we don't have implementations is because of this confusion, and implementors don't know what to do.
<myles> krit: Are those requests coming from implementors?
<myles> AmeliaBR: ....
<myles> krit: We should bring this back to another Working Group. Or WHATWG?
<myles> krit: Maybe someone can follow up on public-script-???
<myles> AmeliaBR: They have a github repo, this is the best place to go.
<AmeliaBR> https://github.com/heycam/webidl/issues
<myles> krit: AmeliaBR, can you follow up with heycam?
<AmeliaBR> s/???/coord/
<myles> krit: AmeliaBR, and possibly bring this up on the mailing list?
<myles> AmeliaBR: Okay I will 1) confirm that we don't have any implementations 2) follow up with WebIDL with two conflicting mixins.
<myles> AmeliaBR: Then we can come back and make a decision with more information.
1 remaining item
longsonr commentedon Jul 15, 2019
I just put all the attributes inline https://dxr.mozilla.org/mozilla-central/source/dom/webidl/SVGAElement.webidl since you can't have conflicting attributes
AmeliaBR commentedon Jul 15, 2019
Thanks, Robert. So, we do have at least one implementation of the rest of the interface.
longsonr commentedon Jul 15, 2019
At the time I implemented it I expected Edge to implement it too: web-platform-tests/wpt#10275 (comment)
lukewarlow commentedon Sep 9, 2025
Should SVGAElement just stop including
HTMLHyperlinkElementUtils? It's not implemented in any of the 4 engines I checked.The alternative would just be move href to the HTMLAnchorElement and HTMLAreaElement interfaces directly?
longsonr commentedon Sep 9, 2025
Or create another interface with the common components everything can implement.
lukewarlow commentedon Sep 9, 2025
Yeah true a
HyperlinkElementUtilsmixin which includes all but href and then HTMLHyperlinkElementUtils can just use that + have the href.I'm not sure if a mixin can include or extend a mixin off the top of my head but either way we could do that in some form.
I guess do we think these things are actually needed?
Saying that there's some existing duplicates between the HTMLAnchorElement and SVGAElement so perhaps they can be moved to the shared mixin too?
lukewarlow commentedon May 5, 2026
The initial fix for the conflict is #1052
Once that's merged we can start to move some of the duplicated properties (target, download, rel) up to the HyperlinkElementUtils mixin, that way MathML can get them for free too.
longsonr commentedon May 7, 2026
@lukewarlow target is going to be a problem to move because that's an SVGAnimatedString. The other attributes added post SVG 1.1 should be OK.
nikolaszimmermann commentedon Sep 9, 2026
@karlcow - the proposal from @lukewarlow is sane. I think we should get it merged.
longsonr commentedon Sep 9, 2026
See https://bugzilla.mozilla.org/show_bug.cgi?id=2058578
karlcow commentedon Sep 9, 2026
Thanks added a couple of editorial comments. Once @lukewarlow fixed them, I will merge.
Thanks everyone !