1258270 - Support calc() on stroke-width, stroke-dasharray and stroke-dashoffset

Status: RESOLVED DUPLICATE of bug 1218257

(Core :: CSS Parsing and Computation, defect, P3)

Description

[Boris Chiou [:boris]]

Bug 594933 implemented calc() on line-height and Bug 1218257 will implement calc() on stroke-dashoffset. We still need calc() on stroke-width and stroke-dasharray.

Comment 1

[Boris Chiou [:boris]]

We'd like to support calc() on properties that accept <number> values, so in this bug, I think we should implement these items:
1. stroke-dasharray:
   The property value of stroke-dasharray is "none | <dasharray>", and
   "<dasharray>" is "[ <length> | <percentage> | <number> ]#*" [1].
   In this bug, I think we could add calc() into <dasharray>, so it'd be like this:
   "[ <length> | <percentage> | <number> | <calc()> ]#*".

2. stroke-width:
   The spec [2] says, the value of stroke-width is "<percentage> | <length>", and
   I don't see the <number> in it, so I'm not sure if implementing calc() in stroke-width is acceptable.
   However, CSS-value-3 [3] says "It can be used wherever <length>, <frequency>, <angle>,
   <time>, <number>, or <integer> values are allowed.", so I think we still could support calc() on stroke-width.
   Let the value of stroke-width be "<percentage> | <length> | <calc()>".

[1] https://svgwg.org/svg2-draft/painting.html#DataTypeDasharray
[2] https://svgwg.org/svg2-draft/painting.html#StrokeWidth
[3] https://drafts.csswg.org/css-values-3/#calc-notation

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Part of the reason these are interesting is that SVG properties allow raw numbers (meaning pixels) in place of lengths.  See the CSS_PROPERTY_NUMBERS_ARE_PIXELS flag.  The other property that does this is stroke-dashoffset (bug 1218257).  So the calc() code for these properties needs to treat <number> values as pixel lengths, but only in the appropriate places.

For all three properties, there would be a stored calc() in the style structs.  So it's possible this transformation could happen relatively late -- which is different from the way <number> works normally for these properties (converted relatively early).

I haven't thought about the problem enough to think about what I think the best solution is, but happy to discuss further later.  (I'm in a meeting now, though, so just writing a brief comment.)

Comment 3

[Boris Chiou [:boris]]

I'm working on other bugs in this quarter, so remove the assignee.

Comment 5

[Springtime]

I see this was closed as a dupe of bug #1218257 (marked fixed in v67) yet I tested on v72.0.2 stable and setting a calc value for stroke-width doesn't appear to change it, instead falling back to the default 1 stroke-width.

Eg: using embedded CSS within an SVG and applying stroke-width: calc(2 * 4); to a path doesn't affect its stroke-width, yet does in Chromium which additionally supports utilizing CSS variables for stroke-width with calc (as it seems to for everything else I've encountered).

Comment 6

[Emilio Cobos Álvarez (:emilio)]

It works if you properly specify the unit, like: calc(2px * 4).

Also, chrome doesn't seem to behave as I'd expect either: stroke-width: calc(2 * 2); does parse, but it gives me a computed value of 2px instead of 4px. It gives me 0px in Safari. stroke-width: calc(2px * 2) works as I'd expect in all browsers.

It's unclear to me if that case is working as per spec or not, seems to me like numbers are ambiguous in calc() expressions like that.

I'll file bugs in other browsers / the spec to hopefully get them to behave like Firefox does.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I filed https://github.com/w3c/csswg-drafts/issues/4874 and bugs for other browsers as linked above.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Using CSS variables seems to work as expected here too, if there are units specified.