Re: [svgwg] Do we really need not to reflect additional enum values in SVG 2

The Working Group just discussed `Do we really need not to reflect additional enum values in SVG 2`, and agreed to the following:

* `RESOLVED: Where SVG 2 has added a new attribute value for an attribute that has an existing DOM enumeration, we will add matching new enumeration values`

<details><summary>The full IRC log of that discussion</summary>
&lt;BogdanBrinza> topic: Do we really need not to reflect additional enum values in SVG 2<br>
&lt;BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/424<br>
&lt;AmeliaBR> Bogdan: We discussed this briefly on the last calll, but deferred a resolution<br>
&lt;AmeliaBR> Amelia: I think, if we aren't going to add new values for new attributes, then we should just deprecate the entire enum, because it's rather confusing as is.<br>
&lt;AmeliaBR> Dirk: For WebKit, I think I had to add special cases to test whether a value was in the SVG 1.1 set or a new value.<br>
&lt;AmeliaBR> Amelia: So it's possible that by not adding the new values, we just complicate implementations anyway?<br>
&lt;AmeliaBR> Bogdan: I agree with David's point on the issue.<br>
&lt;AmeliaBR> Amelia: Meaning, you agree with Robert Longson's original proposal, that we SHOULD expose the new attribute values through the DOM?<br>
&lt;AmeliaBR> David: Yes, and it looks like Firefox already has a bug for exposing a new value?<br>
&lt;AmeliaBR> Amelia: But what new value are they exposing, if it's never defined as an enum constant?<br>
&lt;AmeliaBR> Dirk: But internally they need a value, and it's probably just an ordered int. So we can follow Firefox.<br>
&lt;AmeliaBR> Amelia: Well, it looks like we have agreement between implementers. And for authors it would definitely be an improvement.<br>
&lt;AmeliaBR> ... Do we know all the places this is an issue?<br>
&lt;AmeliaBR> Dirk: There are two places, for markers and for filter blend mode.<br>
&lt;AmeliaBR> ... I'm not sure if both are even implemented.<br>
&lt;AmeliaBR> Amelia: Both are existing attributes, existing enums, with new attribute values but not yet new enum values.<br>
&lt;AmeliaBR> ... I'd assume we want both to be consistent.<br>
&lt;AmeliaBR> RESOLVED: Where SVG 2 has added a new attribute value for an attribute that has an existing DOM enumeration, we will add matching new enumeration values<br>
</details>


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

Received on Monday, 7 May 2018 19:28:57 UTC