1530525 - vector-effect non-scaling-stroke ignored when resized via css background

Status: RESOLVED DUPLICATE of bug 1524901

(Core :: SVG, defect, P3)

Description

[Eric A. Meyer]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Loaded https://meyerweb.com/eric/css/tests/firefox/svg-vector-scaling/ in Firefox Nightly.

Actual results:

In Firefox, the black "X" shape (an external SVG) is stretched as it fills out the background area of each list item. This causes the stroke-width="2" vector-effect="non-scaling-stroke" lines to be thinner or thicker than the declared width, despite the vector-effect value.

Expected results:

What happens in Chrome: the lines should be the same visual width regardless of how they are transformed in order to fit the background area of each list item, which is what vector-effect="non-scaling-stroke" is meant to accomplish.

Comment 1

[Eric A. Meyer]

Possibly related: bug #858317, bug #942174, bug #1247218, bug #1265666, bug#1318208, bug #1413126.

Comment 2

[Liviu Seplecan]

I've tested the issue on several machines: Mac OS X, Ubuntu 16.04, Windows 10 - Firefox versions: latest nightly 67.0a1, beta 66.0b12, release 65.0.2.
The issue can be reproduced on all Firefox versions. Please notice the connection between this issue and above provided by @Eric.

Comment 3

[Cameron McCormack (:heycam)]

Thanks for the bug report, Eric.

According to the SVG specification, the transform that vector-effect:non-scaling-stroke should counteract is the one from the current coordinate space up to the furthest ancestor <svg> element. So that doesn't include any transforms caused by CSS image sizing.

Robert, do you think CSS image sizing is something that should be taken into account here, or is this just a bug in Chrome?

Comment 4

[Cameron McCormack (:heycam)]

https://svgwg.org/svg2-draft/painting.html#PaintingVectorEffects

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Cameron McCormack (:heycam) from comment #3)

According to the SVG specification, the transform that vector-effect:non-scaling-stroke should counteract is the one from the current coordinate space up to the furthest ancestor <svg> element.

Strictly speaking, the spec uses the term "the furthest ancestral SVG viewport" (emphasis added). And in this case, I'd say that the relevant "SVG viewport" is the specified-sized rectangular background region that the image is rendered into.

For comparison, note that we get "expected results" (skinny stroke regardless of px sizing) from a sized <img> element:

  <img src="X.svg" style="height:400px; width:400px">

But the stroke grows with the px sizing if you use background-size as in:

  <div style="width:400px; height: 400px;
               background: url(X.svg);
               background-size: 400px 400px;">

Intuitively it seems like these scenarios should be equivalent.

So that doesn't include any transforms caused by CSS image sizing.

I agree that e.g. CSS transforms and other paint-time graphical effects outside of the SVG content shouldn't be taken into consideration (i.e. shouldn't be counteracted) -- but the known-in-advance CSS-pixel-valued size of the viewport should probably be taken into consideration.

Comment 6

[Cameron McCormack (:heycam)]

Ah, well spotted -- the distinction between viewport and element here does make a difference.