- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 30 Jul 2018 20:27:51 +0000
- To: public-svg-issues@w3.org
The Working Group just discussed `Enum values`, and agreed to the following: * `RESOLVED: Do not extend the SVG_LENGTHTYPE_* and SVG_ANGLETYPE_* constants & enumeration for new CSS units.` * `RESOLVED: If a length/angle was declared using a unit not in the enum, it should be exposed as type UNKNOWN.` <details><summary>The full IRC log of that discussion</summary> <AmeliaBR> Topic: Enum values<br> <AmeliaBR> Github: https://github.com/w3c/svgwg/issues/424<br> <AmeliaBR> Dirk: We agreed to add new enums for things like marker orientation and blend modes, where we have new attribute values.<br> <AmeliaBR> ... But then a question was raised about things like SVGLength unit types, do we want to support the new CSS units.<br> <AmeliaBR> ... David commented that Edge does not have these, and I know that WebKit doesn't. I added a few hacks to work around that.<br> <AmeliaBR> ... So do we want to add things? CSS could add more units, hard to keep up.<br> <AmeliaBR> Amelia: I think we should make sure there is clear behavior for units that don't have a reflected value.<br> <AmeliaBR> Dirk: Agree, but the first question is should we try to extend the list.<br> <AmeliaBR> Amelia: I don't think so. Too difficult to keep up with new units, and CSS Typed OM should eventually replace it anyway.<br> <AmeliaBR> Proposed RESOLVED: Do not extend the SVG_LENGTHTYPE_* and SVG_ANGLETYPE_* constants & enumeration for new CSS units.<br> <AmeliaBR> RESOLVED: Do not extend the SVG_LENGTHTYPE_* and SVG_ANGLETYPE_* constants & enumeration for new CSS units.<br> <AmeliaBR> Dirk: Can we add a link to CSS Typed OM in the spec?<br> <plh> --> https://www.w3.org/standards/history/css-typed-om-1 CSS Typed OM<br> <AmeliaBR> Amelia: A note is easy. Won't automatically apply for all SVG attributes, but will apply for those that have been upgraded to CSS properties.<br> <AmeliaBR> Dirk: Other attributes won't use CSS properties, anyway.<br> <AmeliaBR> Amelia: Not necessarily. We sometimes use CSS syntax for attribute values that aren't CSS properties.<br> <AmeliaBR> Dirk: Probably need to reconsider that. Not sure if browsers use them.<br> <AmeliaBR> Amelia: Yes, last I checked browsers are very wonky about new units (and calc) in SVG attributes, including ones that *do* map to CSS properties.<br> <AmeliaBR> Dirk: I'd prefer to have a clearer distinction between presentation attributes & parsing vs others.<br> <AmeliaBR> Amelia: Either way, we still need guidelines on what to do with the legacy DOM interfaces when new units are used.<br> <AmeliaBR> Dirk: Looking at the enum value, there is an "UNKNOWN" value, so that makes sense to use.<br> <AmeliaBR> Amelia: Yes, but not sure how that affects the rest of the interface & math methods. Can we still convert it to the px value or other units?<br> <AmeliaBR> Dirk: Need to check the existing spec & implementations. Probably make it able to convert to the simple number value, but not the rest.<br> <AmeliaBR> Tav: If it's a lot of work to *not* update the list, would it be easier to just update it?<br> <AmeliaBR> Dirk: Either way, with new units being proposed, we'd still need to define what happens.<br> <AmeliaBR> Amelia: I do agree that the focus should be to keep it as simple as possible. Unknown unit, but still make the simple user-unit value still returns a valid number.<br> <AmeliaBR> ... Either way, should be a separate issue to discuss the details.<br> <AmeliaBR> Proposed: If a length/angle was declared using a unit not in the enum, it should be exposed as type UNKNOWN.<br> <AmeliaBR> RESOLVED: If a length/angle was declared using a unit not in the enum, it should be exposed as type UNKNOWN.<br> <plh> Next meeting is August 13<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-408998878 using your GitHub account
Received on Monday, 30 July 2018 20:27:53 UTC