You might want to rename the section titles accordingly, too.

You mean the "Interface" headlines? If I am right currently, Peters script relies on patterns to detect IDL interfaces in the SVG spec.

@plinss can you in/confirm and possibly fix?

The is a heuristic that marks section headings as an interface definition, if the heading’s anchor starts with “Interface”, and the heading text starts with “Interface “. This was put in for the old SVG spec.

I can update the heuristic if necessary, but you can also simply put a ‘data-dfn-type=interface’ attribute on the header if you’re going to edit it (the heuristics were meant to capture data from old specs without having to update them, if you’re editing the spec, or writing a new one, better to be explicit).

@tobie What do you propose as headline pattern for the mixins?

@plinss Thanks a lot for your comment.

DOM uses "Mixin Foo," HTML: "The Foo Mixin."

@tobie "Mixin Foo" seems more in line with the interface definitions in SVG.

@plinss Currently we use <h3 id="InterfaceSVGAnimatedPoints">Interface SVGAnimatedPoints</h3> in the spec. This would change to <h3 id="InterfaceSVGAnimatedPoints" data-dfn-type="interface">Mixin SVGAnimatedPoints</h3>. Is your script able to detect SVGAnimatedPoints from the title? Should there be another indication for your script to detect the mixin name? (Note: I'd like to keep the ID consistent)

Ah, good catch. When the heuristics match, the spec parser also synthesizes linking text from the heading content (whatever was after “Interface “). To keep that working, also add a ‘data-lt’ attribute, e.g. ‘data-lt=SVGAnimatedPoints’.

Agreed to not change the ID.

Any update on this? Would be great to get it merged. We need this merged before we can include tabindex/focus/blur/dataset as a mixin from HTML. whatwg/html#3543 (I'm writing tests for that now as part of the SVG2 §4 testing task I was given)

In general, I'm supportive of the change. My main concern for reviewing is to make sure that you've caught all the relevant references. Below I summarize the changes made & the checks I made against them:

The following have been converted from NoInterfaceObject interfaces to Mixins:

• SVGTests (included in SVGGraphicsElement, and in SVGAnimationElement in the animation module)

• SVGFitToViewBox (included in SVGSVGElement, SVGSymbolElement, SVGMarkerElement, SVGPatternElement, SVGViewElement)

• SVGZoomAndPan (included in SVGSVGElement, SVGViewElement)

• SVGURIReference (included in SVGUseElement, SVGMeshElement, SVGTextPathElement, SVGImageElement, SVGGradientElement, SVGPatternElement, SVGCursorElement, SVGScriptElement, SVGAElement, and SVGMPathElement in the animation module)

• SVGElementInstance (included in SVGElement)

• GetSVGDocument (designed to be compatible with HTMLIframeElement and HTMLObjectElement, but those interfaces currently define the method directly instead of implementing the interface, so we're not breaking anything there, although a follow-up PR could suggest they switch to the mixin structure)

• SVGAnimatedPoints (included in SVGPolylineElement and SVGPolygonElement)

• SVGPathData in the Paths Level 3 module

Those are all the eligible NoInterfaceObject interfaces in SVG 2, and all the interfaces that currently implement. I haven't checked the other modules myself, but I'm less worried about those since we're not asking anyone to implement them yet.

In addition, the following mixins defined in the HTML standard are now references as includes not implements:

• GlobalEventHandlers (included in SVGElement)
• WindowEventHandlers (included in SVGSVGElement)
• HTMLHyperlinkElementUtils (included in SVGAElement)

However, those interfaces are still being linked to W3C HTML 5.1 definitions, which used the NoInterfaceObject syntax (as does HTML 5.3 ED). The link URLs are defined in definitions.xml, but there should be a WG resolution before switching from W3C to WHATWG as the definitive reference for HTML (we're not consistent throughout the spec prose, linking to either/both, but IDL is more formal).

Also note that there is an open issue about conflicts implementing HTMLHyperlinkElementUtils in SVG elements (although nothing in this PR makes that a bigger or smaller conflict).

The only other potentially-mixin interface implemented in SVG is LinkStyle (but that would need edits to CSSOM first, and then an update to SVG's reference definition URL to point to CSSOM instead of CSS 2).

Final comment: There should be an edit made to the changes appendix describing these changes (one line in the "changes to the entire spec" section should be fine).

That & a WG decision on cross-linking to the HTML specs, and I'd be able to sign off on this PR.

For CSSOM the PR is w3c/csswg-drafts#2123

FWIW Edge implements GetSVGDocument as a mixin for both SVG and HTML interfaces. I guess we should have an issue either here or on HTML to decide which way to go.

Yeah HTMLHyperlinkElementUtils is outside of this, but AFAICT no one supports it on SVG.

CSSOM has been updated now, so we just need to point to that to solve that particular problem.

Naïve newbie question: is it strictly necessary for W3C HTML to update to the new WebIDL syntax for mixins for us to change to the new syntax for including them on our interfaces? They`re still mixins in the old syntax. just that there was no official WebIDL syntax for expressing that cleanly.

If so maybe one of my ex-Opera chums @brucelawson @cynthia , @patricia-gallardo , @shwetank, can help with merging that change into the W3C version (still doesn't help that we still reference 5.1)

is it strictly necessary for W3C HTML to update to the new WebIDL syntax for mixins for us to change to the new syntax for including them on our interfaces?

I'm certainly not an expert on Web IDL syntax. It might not make a big deal. The Web IDL spec clearly describes the old usage of [NoInterfaceObject] and implements as being equivalent to a mixin and includes, even if it is a deprecated syntax. Maybe @heycam can weigh in as the official arbiter of Web IDL syntax rules.

(still doesn't help that we still reference 5.1)

We could at least update our definitions to use https://www.w3.org/TR/html/ or https://www.w3.org/TR/html5/ as the base URL, which currently point to 5.2, but would get updated when 5.3 is published. If it's likely that 5.3 will include the new IDL syntax and get published before we next update an SVG 2 CR, that would solve that issue without a W3C vs WHATWG debate.

@dirkschulze
Are you able to make the following changes?

• Add the mixin syntax for LinkStyle, and update the definitions.xml to point to the TR version of CSSOM (which will hopefully eventually be republished with the new syntax).
• Update the definitions.xml references to HTML to use the unversioned TR URLs.
• Add an entry to changes.html with a brief mention of the syntax change (being sure to mark it as a change since last publication).

If you're not likely to get to it in the next week or so, I suspect that @dstorey would make the changes if you asked.

Also pinging @tobie on the question about if it is ok to use the new mixin syntax if the spec we reference that defines the mixin hasn't updated yet. He wrote the PR so will probably known.

@dstorey Is this still the case with master? I don't think anyone plans to update 5.1.

Also pinging @tobie on the question about if it is ok to use the new mixin syntax if the spec we reference that defines the mixin hasn't updated yet. He wrote the PR so will probably known.

Well, technically that behavior is unspecified. So, for example, the algorithm to get the exposure set of a WebIDL construct might return something completely weird. I'd suggest adding a note to the spec that says included interfaces must be treated as if it they were interface mixins… and aim to get that fixed as soon as possible.

@cynthia

Is this still the case with master? I don't think anyone plans to update 5.1.

It's still the case with the Editor's Draft, and I don't see any PR or issues discussing the mixin syntax as an option.

@AmeliaBR That is good to know - feel free to raise an issue about this if you think this needs to be looked into.

One other change required: We'll need to update the references to point to the "living standard" version of WebIDL (AKA, the Editor's Draft), instead of the TR Level 1.

(Unless @tobie or @heycam tell us that there is a likelihood of a TR Level 2 spec with the updated syntax in the near future.)

Use SpecRef as the basis for the markup (we are, sadly, not automagically linked to them).

Is this something you're still able to get time to do @dirkschulze ? I believe this is just updating the change log and references now.

@AmeliaBR wrote:

One other change required: We'll need to update the references to point to the "living standard" version of WebIDL (AKA, the Editor's Draft), instead of the TR Level 1.
(Unless @tobie or @heycam tell us that there is a likelihood of a TR Level 2 spec with the updated syntax in the near future.)

I'm not too sure what the story around the WebIDL leveled specs is, tbh. Nor do I know who's in charge of publishing these or what their timeline is, if any.

I recommend treating WebIDL as a living standard.

@dstorey I will do the suggested edits by @AmeliaBR in #376 (comment) in the next couple of days.

Thanks @dirkschulze!

If we go ahead with #60, we'll probably update the HTML references again, to point to WHATWG, but this is an improvement for now.

I can make that change. The change is already in HTML and I need WHATWG references for other changes