Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stroke-width initial value must include units #529

Closed
sideshowbarker opened this issue Aug 17, 2018 · 17 comments
Closed

stroke-width initial value must include units #529

sideshowbarker opened this issue Aug 17, 2018 · 17 comments
Assignees

Comments

@sideshowbarker
Copy link
Contributor

At https://svgwg.org/svg2-draft/painting.html#StrokeWidthProperty, the initial value must not be just 1; instead the units must be explicitly included — so it needs to be 1px.

That’s per the chain of syntax requirements from https://drafts.csswg.org/css-values-4/#typedef-length-percentage to https://drafts.csswg.org/css-values-4/#length-value to https://drafts.csswg.org/css-values-4/#dimension that the SVG spec normative includes by reference (due to citing https://www.w3.org/TR/css-values/#typedef-length-percentage) — which indicate that a <length-percentage> value must include units if it’s a length.

See also https://drafts.fxtf.org/fill-stroke/#stroke-width, which correctly has the initial value as 1px instead of just 1.

@AmeliaBR
Copy link
Contributor

The stroke-width syntax should actually be <length-percentage> | <number>, since plain numbers are valid in CSS properties, not only presentation attributes. Must have got dropped when converting to the <length-percentage> syntax.

But I don't see a problem with making the initial value have units, since the computed value is always converted to absolute length anyway.

@ewilligers
Copy link
Contributor

The stroke-width syntax should actually be <length-percentage> | <number>, since plain numbers are valid in CSS properties, not only presentation attributes.

Confirmed support for plain numbers in all browsers. There are a couple of implementation bugs: Only Safari changes "10" to "10px" when serializing. Only Firefox gives "10" as the computed style. Neither has these bugs for line-height.

@sideshowbarker
Copy link
Contributor Author

The stroke-width syntax should actually be <length-percentage> | <number>, since plain numbers are valid in CSS properties, not only presentation attributes.

I’m not sure what you mean by “plain numbers are valid in CSS properties” but as far as the CSS stroke-width property specifically, unit-less numbers aren’t valid values for it per https://www.w3.org/TR/fill-stroke-3/#stroke-width and https://drafts.fxtf.org/fill-stroke/#stroke-width, which both define the allowed value as <length-percentage>.

Confirmed support for plain numbers in all browsers.

It’s unsurprising that browsers accept and process unit-less numbers in the value. The issue here isn’t about the processing behavior/requirements in browsers; instead it’s about the document-conformance requirements — the authoring rules.

And naively I’d assume that a goal here is to be consistent with how the CSS specs define the document-conformance requirements for CSS stroke-width property. And the relevant CSS specs at https://www.w3.org/TR/fill-stroke-3/#stroke-width and https://drafts.fxtf.org/fill-stroke/#stroke-width both state the allowed value is <length-percentage> and the initial value is 1px.

@AmeliaBR
Copy link
Contributor

I’m not sure what you mean by “plain numbers are valid in CSS properties” but as far as the CSS stroke-width property specifically, unit-less numbers aren’t valid values…

In SVG 1 and SVG 2, a unitless number is always allowed as a length in a presentation attribute (even for old CSS properties like font-size), where it is processed into a px value.

SVG 1 also always allowed a unitless number as a length "for properties defined in SVG", extending the CSS definition. In SVG 2, we made these syntax options explicit for properties defined in SVG 1 (changing <length>|<percentage> to <length-percentage>|<number>), and resolved not to add the same behavior for new properties.

But stroke-width was defined and universally implemented in SVG 1, so it needs to have the full syntax that was valid in SVG 1, including <number>.

@AmeliaBR AmeliaBR reopened this Aug 20, 2018
@AmeliaBR
Copy link
Contributor

(The "relevant CSS specs" are the same spec at different URLs, and both were created by copy & pasting the error from SVG 2!)

@dirkschulze
Copy link
Contributor

We also need to validate the initial value in browsers. Maybe it is 1 after all.

@dirkschulze
Copy link
Contributor

We might need to add some tests and wording for the computed value and number as well.

@ewilligers
Copy link
Contributor

We also need to validate the initial value in browsers. Maybe it is 1 after all.

When 'initial' is specified, all browsers give 'initial' as serialized value and '1px' as computed value.

@sideshowbarker
Copy link
Contributor Author

(The "relevant CSS specs" are the same spec at different URLs, and both were created by copy & pasting the error from SVG 2!)

ah, I see — thanks

So then, can somebody raise an issue for this at https://github.com/w3c/fxtf-drafts/labels/fill-stroke-3 — or maybe better yet, a pull request there? (I’d offer to do it myself but I think it would be better done by somebody who’s familiar with the provenance.)

The reason I care about this is that the CSS validator currently reports an error for unit-less values of the CSS stroke-width property — because that’s what https://drafts.fxtf.org/fill-stroke/#stroke-width currently requires.

But if https://drafts.fxtf.org/fill-stroke/#stroke-width can be updated to allow <number>, then I can update the CSS validator to make it quit reporting an error for that.

@svgeesus
Copy link
Contributor

The reason I care about this is that the CSS validator

I'm not sure why we should care about the CSS validator. It doesn't track the specifications, doesn't handle svg in html5 well, and gives more false negatives than useful information.

@sideshowbarker
Copy link
Contributor Author

I'm not sure why we should care about the CSS validator. It doesn't track the specifications, doesn't handle svg in html5 well, and gives more false negatives than useful information

When was the last time you tried it? I’ve actually put many hours of work this year into bringing it up to date, and @ylafon has put many more into it than I ever will.

You and @tabatkins might want to take a look through https://github.com/w3c/css-validator/commits/master

It’s pretty disheartening to have a couple of people in positions of leadership in the CSS WG expressing (and thumbs-upping) those kinds of sentiments. It’s not constructive, it doesn’t help the conversation here in any way — and it’s personally really demoralizing to me, as one of the people who’s put significant effort this year into improving the CSS validator.

You really bummed me out with that. Maybe you figure @ylafon and I should just quit caring about the CSS validator too? And quit trying to improve it?

@ewilligers
Copy link
Contributor

So then, can somebody raise an issue for this at https://github.com/w3c/fxtf-drafts/labels/fill-stroke-3 — or maybe better yet, a pull request there?

I will as part of #534. For stroke-width we need to update two specs, and raise two browser bugs with a WPT. But first I'll investigate if there are also more properties affected.

@sideshowbarker
Copy link
Contributor Author

So then, can somebody raise an issue for this at https://github.com/w3c/fxtf-drafts/labels/fill-stroke-3 — or maybe better yet, a pull request there?

I will as part of #534. For stroke-width we need to update two specs, and raise two browser bugs with a WPT. But first I'll investigate if there are also more properties affected.

Thanks!

@dd8
Copy link

dd8 commented Oct 16, 2018

The SVG 1.1 and 2.0 specs only allow a single value for stroke-width:
https://www.w3.org/TR/SVG11/painting.html#StrokeWidthProperty
https://svgwg.org/svg2-draft/painting.html#StrokeWidthProperty

The CSS Fill and Stroke Module Level 3 draft indicates multiple values are allowed for stroke-width
https://www.w3.org/TR/fill-stroke-3/#stroke-width

Value: <length-percentage>#

A hash mark (#) indicates that the preceding type, word, or group occurs one or more times
https://drafts.csswg.org/css-values-4/#mult-comma

Hard to think of any way to use multiple values for stroke-width - is this a typo?

@AmeliaBR
Copy link
Contributor

@dd8 Not a typo. The new spec allows multiple, layered strokes. So you could draw a thin stroke in one color on top of a thick stroke in another color. Or a dashed stroke on top of a solid-colored stroke. The feature was initially proposed for SVG 2, but was deferred.

@dirkschulze dirkschulze self-assigned this Oct 27, 2018
dirkschulze added a commit that referenced this issue Nov 10, 2018
… values for old CSS properties, align computed styles, fix prop index. #534, #529, #555
dirkschulze added a commit that referenced this issue Nov 26, 2018
… values for old CSS properties, align computed styles, fix prop index. #534, #529, #555
@dirkschulze
Copy link
Contributor

Fixed, closing.

@ewilligers
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants