- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 May 2018 19:28:42 +0000
- To: public-svg-issues@w3.org
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> <BogdanBrinza> topic: Do we really need not to reflect additional enum values in SVG 2<br> <BogdanBrinza> GitHub: https://github.com/w3c/svgwg/issues/424<br> <AmeliaBR> Bogdan: We discussed this briefly on the last calll, but deferred a resolution<br> <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> <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> <AmeliaBR> Amelia: So it's possible that by not adding the new values, we just complicate implementations anyway?<br> <AmeliaBR> Bogdan: I agree with David's point on the issue.<br> <AmeliaBR> Amelia: Meaning, you agree with Robert Longson's original proposal, that we SHOULD expose the new attribute values through the DOM?<br> <AmeliaBR> David: Yes, and it looks like Firefox already has a bug for exposing a new value?<br> <AmeliaBR> Amelia: But what new value are they exposing, if it's never defined as an enum constant?<br> <AmeliaBR> Dirk: But internally they need a value, and it's probably just an ordered int. So we can follow Firefox.<br> <AmeliaBR> Amelia: Well, it looks like we have agreement between implementers. And for authors it would definitely be an improvement.<br> <AmeliaBR> ... Do we know all the places this is an issue?<br> <AmeliaBR> Dirk: There are two places, for markers and for filter blend mode.<br> <AmeliaBR> ... I'm not sure if both are even implemented.<br> <AmeliaBR> Amelia: Both are existing attributes, existing enums, with new attribute values but not yet new enum values.<br> <AmeliaBR> ... I'd assume we want both to be consistent.<br> <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