[fill-stroke] stroke-width and stroke-dasharray accept numbers

[ewilligers]

All browsers support numeric values for stroke-width and stroke-dasharray.

<length-percentage> should change to [<length-percentage> | <number>].

Precedent: https://svgwg.org/svg2-draft/types.html#syntax
"Replace all instances of <length-percentage> in grammar with [<length-percentage> | <number>]."

[ewilligers]

Note that Blink and Safari, and also Edge when in Quirks mode, support numeric values for baseline-shift.

[ewilligers]

Blink and Safari also support numeric property values for cx cy r rx ry x y. All of the geometry properties and baseline-shift have exceeding low <number> usage as properties.

However, stroke-width and stroke-dasharray each have approximately 1% <number> usage as properties:
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/stroke-dashoffset/
https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/stroke-width/

The SVG WG is open to to accepting numeric values for the geometry properties (given that two engines have shipped support), but it was noted that they may become general CSS properties in future, hence the need to check these too with CSS WG.

[heycam]

Agree that stroke-width / stroke-dasharray should support numbers in the properties. I would prefer not to support plain numbers in new presentation attributes for existing SVG properties, but I can see the appeal of consistency with the original SVG properties.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: stroke-width and stroke-dasharray accept numbers
<dael> github: https://github.com//issues/3057
<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
<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
<dael> AmeliaBR: Found a couple cases not properly updated including stroke-width.
<dael> AmeliaBR: eric did a review
<AmeliaBR> https://docs.google.com/spreadsheets/d/1HRzb_-S28xq7GqYKhHbMP2YQlqWLvOWSS_twLXy-I40/edit?usp=sharing
<dael> AmeliaBR: Spreadsheet of which properties accept unlitless #^
<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
<dael> AmeliaBR: B/c it's a general CSS syntax issue wanted to bring it to the full WG
<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.
<dael> AmeliaBR: You think treat as only for legacy and don't do it in any new properties
<dael> fantasai: Yes
<dael> AmeliaBR: That would affect geometry prop.
<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
<TabAtkins> We've got a <quirky-length> production (defined in Quirks spec) for handling "unitless px lengths".
<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
<dael> heycam: not allow for anything like geometry
<dael> myles: Aside from web compat this is [missed]
<myles> s/[missed]/a fine direction/
<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
<dael> Rossen_: We prefer keep attributes the way they are and all CSS properties to continue to support lengths as they do today
<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
<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
<AmeliaBR> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/baseline-shift/
<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.
<dael> AmeliaBR: Little used property outside of certain SVG editors. It's showing up once in Edge's scan with unitless
<dael> fantasai: Then we should eliminate this parsing quirk
<dael> heycam: And I guess that's what spec required. Referencing CSS text already doesn't have unitless number
<dael> fantasai: Need to update stroke, can you tag the float stroke spec?
<dael> AmeliaBR: Yeah
<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
<dael> fantasai: Accept for those with a webcompat constraint is what I would say
<dael> Rossen_: Objections?
<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
<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
<dael> dbaron: Saying 'quirk' is dangerous because it sounds like it's in quirks mode
<dbaron> s/in quirks mode/quirks mode only/
<dael> heycam: Looking through the SVG1.1 property list and those that don't have a CSS prop only other is stroke-[mimssed]
<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.
<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
<dael> AmeliaBR: There's lots of properties where we do accept it but we updated syntax to say they accept number
<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
<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
<heycam> s/stroke-offset/stroke-dashoffset/
<dael> Rossen_: Yes, but we don't want to broadly say all, we want to limit the scope.
<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.
<dael> Rossen_: Preference?
<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
<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.
<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
<dael> Rossen_: Proposal: Only accept unitless values on SVG 1.1 supported properties with the exception of baseline-shift
<dael> RESOLVED: Only accept unitless values on SVG 1.1 supported properties with the exception of baseline-shift
<dbaron> s/experiment with removing something that's interoperable in order to demonstrate webcompat problems/
<dbaron> s/experiment with removing it/experiment with removing something that's interoperable in order to demonstrate webcompat problems/

[stof]

The resolution from 2018 is still not reflected in the draft spec at https://drafts.fxtf.org/fill-stroke-3/#propdef-stroke-dasharray.

Support for <number> in browser is also not fully interoperable. Firefox supports literal numbers at parse time, but does not support <number> produced by calc() as it uses parser quirks to support numbers while keeping the property syntax of the draft spec without that resolution: https://bugzilla.mozilla.org/show_bug.cgi?id=1679465

And because the webref project maintains a custom patch to take that resolution into account, MDN shows the patched formal syntax instead of the syntax in the draft spec in https://developer.mozilla.org/en-US/docs/Web/CSS/stroke-dasharray#formal_syntax

[stof]

@tabatkins @fantasai given that you are listed as editors of the fill-stroke-3 spec, do you know what are the plans regarding that resolution ?