Repository navigation
Add advice on how to handle className conflict in DOM? #298
Description
Re: Interface SVGElement
https://svgwg.org/svg2-draft/single-page.html#types-InterfaceSVGElement
As far as I can tell, this is the first version of the spec since className was added to the Element interface in DOM level 2 (2002). SVGElement in SVG 1.2 Tiny didn't include className in its uDOM definition.
Should the spec provide guidance on how implementations should handle the conflict between SVGElement.className and Element.className?
Activity
[-]Add advice on how to handle className conflict in DOM[/-][+]Add advice on how to handle className conflict in DOM?[/+]AmeliaBR commentedon Dec 8, 2016
What I'd like to do is to have
SVGElement.classNameact as a regular DOM string that has special properties.animValand.baseValthat implement the old SVGAnimatedString behavior. See #175 for my musings about speccing that sort of behavior SVG-wide.In the short term, however, based on existing implementations, the guidance is more that "the
.classNameproperty of SVGElement overrides the property of the same name on theElementinterface".Of course, whether this is easy or hard to implement depends on the type-strictness of the language in which you're implementing the DOM.
nikosandronikos commentedon Dec 9, 2016
Since
SVGElement.classNameis deprecated. It would be nice if we could reverse the order of that and defer toElement.classNameif it exists.AmeliaBR commentedon Dec 9, 2016
That wouldn't be backwards compatible, and doesn't get at the main issue: should implementers move their existing HTMLElement.classname implementations to be part of the core Element interface, or no? If we're saying they should, then SVGElement.classname isn't just deprecated, it's obsolete & any old SVG script references to it will be broken.
AmeliaBR commentedon Dec 22, 2016
On the call today we agreed that--as much as we'd like a more compatible option--for now, we want to spec the current behavior. Meaning that the SVGElement definition of
classNamewould override the inherited definition fromElement.@nikosandronikos has agreed to look into the WebIDL rules on overloading inherited properties to make sure that's allowed, and to add a short clarification/warning to the spec.
nikosandronikos commentedon Dec 23, 2016
The important text in WebIDL is:
Clarify that SVGElement.className overrides Element.className
AmeliaBR commentedon Dec 23, 2016
Thanks Nikos. Yes, I was confusing things by looking at the WebIDL section on overloading, instead of inheritance. Been too long since I've done worked with a traditional object-oriented language where overloading method signatures is a thing.