- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Sep 2018 23:55:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `stroke-width and stroke-dasharray accept numbers`, and agreed to the following: * `RESOLVED: Only accept unitless values on SVG 1.1 supported properties with the exception of baseline-shift` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: stroke-width and stroke-dasharray accept numbers<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3057<br> <dael> AmeliaBR: This is broader then the stroke properties. Background- SVG1 properties were defined in such a way that length data type was extended to allow unitless numbers as length<br> <dael> AmeliaBR: Causes complications. SVG2 we changed so that things were explicit that value for properties from SVG1 that accepted unitless # as length is now explicit in syntax<br> <dael> AmeliaBR: Found a couple cases not properly updated including stroke-width.<br> <dael> AmeliaBR: eric did a review<br> <AmeliaBR> https://docs.google.com/spreadsheets/d/1HRzb_-S28xq7GqYKhHbMP2YQlqWLvOWSS_twLXy-I40/edit?usp=sharing<br> <dael> AmeliaBR: Spreadsheet of which properties accept unlitless #^<br> <dael> AmeliaBR: In addition to stroke-width and stroke-dasharray which is a spec error there is also baseline-shift and all the new SVG geometry properties. Blink and webkit accept unitless numbers on those<br> <dael> AmeliaBR: B/c it's a general CSS syntax issue wanted to bring it to the full WG<br> <dael> fantasai: This was a significant point of contention in the past where CCSS said we need length and SVG said we want unitless. I think before there was a comprimise and I don't remember it. I think CSS properties taking a unitless length and treating it as px shouldn't have happened.<br> <dael> AmeliaBR: You think treat as only for legacy and don't do it in any new properties<br> <dael> fantasai: Yes<br> <dael> AmeliaBR: That would affect geometry prop.<br> <dael> AmeliaBR: Comprimise is special parsing rules in presentation attribute forms where at parse unlitless upgraded to length with px. Because that we can do things where CSS needs a unit<br> <TabAtkins> We've got a <quirky-length> production (defined in Quirks spec) for handling "unitless px lengths".<br> <dael> heycam: We already have a bunch of exampls were presentation attribute accepts and CSS properties need a unit so CSS properties never got a unitless number. I think it's reasonable to not extend any other CSS properties to accept plain numbers in the property and just leave it as the properties needed for SVG, allowing those for numbers<br> <dael> heycam: not allow for anything like geometry<br> <dael> myles: Aside from web compat this is [missed]<br> <myles> s/[missed]/a fine direction/<br> <dael> Rossen_: Add to the discussion what TabAtkins put in IRC. quirk length for Quirks mode does support unitless for length. I'm in favor of not spreading this to other properties or modes<br> <dael> Rossen_: We prefer keep attributes the way they are and all CSS properties to continue to support lengths as they do today<br> <dael> AmeliaBR: WE do have SVG1 properties where there is webcompat need to support. Plan for SVG was to limit to the ones from SVG1. Somehow this slipped through blinka nd webkit impl for geometry properties<br> <dael> AmeliaBR: baseline-shift is the other complication. Significantly redefined in CSS, though originally in SVG1. Not sure if worth switching to more CSS compat syntax or keep it with SVG1 syntax<br> <AmeliaBR> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/baseline-shift/<br> <dael> fantasai: web compat question. If there's no content dependency we should eliminate. If there's content that depends on unitless number things in CSS properties it needs to be incorporated in.<br> <dael> AmeliaBR: Little used property outside of certain SVG editors. It's showing up once in Edge's scan with unitless<br> <dael> fantasai: Then we should eliminate this parsing quirk<br> <dael> heycam: And I guess that's what spec required. Referencing CSS text already doesn't have unitless number<br> <dael> fantasai: Need to update stroke, can you tag the float stroke spec?<br> <dael> AmeliaBR: Yeah<br> <dael> AmeliaBR: Proposal: Unitless number as an alternative to length will only be accepted in those SVG properties that were defined as properties in SVG1.1 except for baseline-shift<br> <dael> fantasai: Accept for those with a webcompat constraint is what I would say<br> <dael> Rossen_: Objections?<br> <dael> Rossen_: Unitless number as an alternative to length will only be accepted in those SVG properties that were defined as properties in SVG1.1 except for baseline-shift and that have a web-compat constraint<br> <dael> fantasai: I think it's: Unitless numbers is limited to SVG1.1 properties where there's a webcompat constraint requiring it. Required for stroke-width and stroke-dasharray. Will not support for baseline-shift<br> <dael> dbaron: Saying 'quirk' is dangerous because it sounds like it's in quirks mode<br> <dbaron> s/in quirks mode/quirks mode only/<br> <dael> heycam: Looking through the SVG1.1 property list and those that don't have a CSS prop only other is stroke-[mimssed]<br> <AmeliaBR> Revised proposal: Unitless number as an alternative to length will only be accepted in those SVG properties where there is a webcompat need. Specifically: stroke-width, stroke-dasharray, stroke-dashoffset will accept it; baseline-shift won't.<br> <dael> heycam: If people have data on if stroke-offset is needed...but given there's only 3 properties maybe we can be clear about the set<br> <dael> AmeliaBR: There's lots of properties where we do accept it but we updated syntax to say they accept number<br> <dael> Rossen_: Agree with what you're saying heycam but we'll have to discuss again. We'll either add or remove properties with more data<br> <dael> AmeliaBR: This is one reason why don't want to make it about web compat but rather that they were dedfined in SVG1.1<br> <heycam> s/stroke-offset/stroke-dashoffset/<br> <dael> Rossen_: Yes, but we don't want to broadly say all, we want to limit the scope.<br> <dael> Rossen_: We can do what heycam said where we only say 3 properties accept or we can go with based on data we'll add and we know for sure about these properties.<br> <dael> Rossen_: Preference?<br> <dael> fantasai: I'd resolve on principle and then refine list. I think we'll include a lot of SVG1.1 Having this number parsing issue limits the future so that's why we want to limit where this is done. Especially where we've taken SVG properties and broadened them. It will be somewhat arbitrary. Webcompat is tightest we can pull the string<br> <dael> dbaron: I don't want to resolve on a principle that requires an impl to experiment with removing it. I thinik if everyone does this for a property we should spec it that way.<br> <dael> AmeliaBR: I was misleading by saying a lot of properties. I guess it really is only the ones we'e talked about. Lots of attributes using CSS syntax made it seem a wider issue<br> <dael> Rossen_: Proposal: Only accept unitless values on SVG 1.1 supported properties with the exception of baseline-shift<br> <dael> RESOLVED: Only accept unitless values on SVG 1.1 supported properties with the exception of baseline-shift<br> <dbaron> s/experiment with removing something that's interoperable in order to demonstrate webcompat problems/<br> <dbaron> s/experiment with removing it/experiment with removing something that's interoperable in order to demonstrate webcompat problems/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3057#issuecomment-418918339 using your GitHub account
Received on Wednesday, 5 September 2018 23:55:52 UTC