Re: [svgwg] SVGAElement implements two conflicting interfaces (#312)

The SVG Working Group just discussed `SVGAElement implements two conflicting interfaces`.

<details><summary>The full IRC log of that discussion</summary>
&lt;krit> topic: SVGAElement implements two conflicting interfaces<br>
&lt;myles> GitHub: https://github.com/w3c/svgwg/issues/312<br>
&lt;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.<br>
&lt;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 &lt;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.<br>
&lt;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.<br>
&lt;myles> krit: The problem is that href is defined in two interface objects, and HTMLAElement implements both.<br>
&lt;myles> AmeliaBR: And WebIDL doesn't define which one wins.<br>
&lt;myles> AmeliaBR: But if you both inherit and override, then WebIDL does define which one wins.<br>
&lt;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.<br>
&lt;myles> AmeliaBR: It requires a dependency on another spec.<br>
&lt;myles> krit: Is it possible to inherit from a non-interface object?<br>
&lt;myles> AmeliaBR: I don't think so. That should be a mixin rather than an interface.<br>
&lt;myles> krit: righ.t<br>
&lt;myles> krit: Another alternative is we don't use HTMLInterfaceHyperlinkUtils<br>
&lt;myles> AmeliaBR: I don't think we have any implementations. I haven't tested<br>
&lt;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<br>
&lt;myles> AmeliaBR: That probably makes sense<br>
&lt;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.<br>
&lt;myles> krit: Are those requests coming from implementors?<br>
&lt;myles> AmeliaBR: ....<br>
&lt;myles> krit: We should bring this back to another Working Group. Or WHATWG?<br>
&lt;myles> krit: Maybe someone can follow up on public-script-???<br>
&lt;myles> AmeliaBR: They have a github repo, this is the best place to go.<br>
&lt;AmeliaBR> https://github.com/heycam/webidl/issues<br>
&lt;myles> krit: AmeliaBR, can you follow up with heycam?<br>
&lt;AmeliaBR> s/???/coord/<br>
&lt;myles> krit: AmeliaBR, and possibly bring this up on the mailing list?<br>
&lt;myles> AmeliaBR: Okay I will 1) confirm that we don't have any implementations 2) follow up with WebIDL with two conflicting mixins.<br>
&lt;myles> AmeliaBR: Then we can come back and make a decision with more information.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/312#issuecomment-511556716 using your GitHub account

Received on Monday, 15 July 2019 20:27:14 UTC