How does vector-effect=non-scaling-stroke interact with the stroke-dash* properties

[fsoder]

In the sections on how vector effects are painted [1], it's stated that:

The resulting visual effect of this modification is that stroke width is not dependant on the transformations of the element...

which does not call out if stroke-dasharray and stroke-dashoffset should be processed in the host coordinate space as well, or if it should be handled in the user coordinate space (somehow).
It does say "Stroke outline is calculated in the host coordinate space.", which could be interpreted to include all the properties that define a stroke shape (per [2].)

[1] https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects
[2] https://svgwg.org/svg2-draft/painting.html#StrokeShape

(This issue surfaced in https://bugs.chromium.org/p/chromium/issues/detail?id=730008)

[AmeliaBR]

As I read it, all the stroke properties are adjusted for the non-scaling-stroke. But I agree, it should be defined more explicitly.

I realize that's going to be frustrating for the common use-case of using stroke-dasharray to animate a single dash the length of the path. But I'd rather solve that by having a better solution for defining dashes proportional to path length (e.g. #177). Then we'd just need to clarify that the effective path length is also converted to adjust for the changed scale.

[Fuzzyma]

I encountered this problem today when i wanted to animate the stroke dashoffset together with animated scale. Even if I do not change the dashoffset at all, the scale affects it. For the userperspective this is just a big "What is going on here". The user should not care if the stroke was scaled or not scaled. The offset should stay at the same spot. Everything else is not useful (correc me if Iam wrong but I dont see a good usecase for that - all you do want from nonscaling stroke is, that your shape does not get messed up only because you scaled it).

[AmeliaBR]

The problem is that there are two very different use cases, where you want different scaling behaviors:

• For a simple repeating dash pattern, like stroke-dasharray: 2 1; stroke-width: 1px, you want the dasharray pattern to stay consistent with the stroke-width. That way, the dashed pattern stays visually the same, you just fit more or fewer dashes around the shape as it scales up or down, so it looks like the dimensions of the path itself has changed.

• However, for the "draw a path with dashes" effect, where the dasharray is defined to match the path length, then you would want the dash length and offset to scale with the path size.

Since the first case is the primary use case, and the second is a bit of a hack that already requires some JS to calculate the path length, my argument is that the dashes should be defined using the same scale as the stroke width.

But either way, it needs to be defined more clearly in the spec.

[dirkschulze]

From the implementation point of view, I think what gets implemented is to transform the path to the host coordinate system and paint the stroke in the host coordinate system. This way, all stroke properties apply in the host coordinate system.

I see that there are use cases to scale some properties, but this is not trivial for non-uniform scales. We would need to fallback to the infamous square root approach to compute the stroke width (or other length based properties).

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[css-meeting-bot]

The SVG Working Group just discussed How does vector-effect=non-scaling-stroke interact with the stroke-dash* properties.

The full IRC log of that discussion

<myles> TOPIC: How does vector-effect=non-scaling-stroke interact with the stroke-dash* properties
<myles> Github: https://github.com//issues/323
<myles> krit: <reads issue titel>
<myles> s/titel/title/
<myles> krit: the question here is when we draw a stroke with a dash array, which coordinate space would the dash array be drawn, the original one or the new one? That's defined by the painting order, draw the stroke as specified by the stroke paint computed ... mumble
<myles> krit: "Compute the shape of the stroke"
<krit> https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects
<myles> krit: I think it's specified already, but does anyone have anything to add here? The section in the stroke of the vector effects shows how you get back to the host coordinate system. It follows to compute the shape of the stroke section. It should clarify the issue.
<myles> AmeliaBR: As Chrome commented on the issue, I think all these properties should have the same scale adjustment. Otherwise it would be very confusing. It would be non-uniform scales.
<myles> krit: right.
<myles> krit: that is my main concern as well.
<myles> krit: You would have triangular, a^2 + b^2 = c^2 ...
<myles> AmeliaBR: yeah.
<myles> krit: I'm not sure, can we close this as no fix? not invalid, but already defined?
<myles> AmeliaBR: it does need clearer text.
<myles> AmeliaBR: ... to make it clear what should happen. We should state that this isn't ideal for some use cases, and we've decided not to chagne for thsoe use cases.
<myles> krit: so, add a note.
<myles> myles: adding a note, or an example, even, would be great.

[dirkschulze]

Example: https://codepen.io/krit/pen/BGpBxa

[monfera]

A possibly analogous question is the behavior of vector-effect="non-scaling-stroke" on <pattern> contents - for example, it's desirable to make it possible that the element using the pattern, when scaled, doesn't also have the line widths scaled. Ie. the stroke-width should be invariant to the scale of the pattern user. Same goes for eg. non-scaling-size / <polygon> and also, not just <pattern> but <marker> and <symbol>. The current workaround of applying the inverse scale onto the contents of these <defs> is counterintuitive as this is what non-scaling-stroke and non-scaling-size purport to achieve to begin with.

PS. looks like mainstream browsers don't do the right thing here and it's a discussion topic here - if it should exist as an issue in this repo too, tell me and I can add it.