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

NEW
Unassigned

Status

()

P3
normal
25 days ago
4 days ago

People

(Reporter: eric, Unassigned, NeedInfo)

Tracking

Trunk
Desktop
All
Points:
---

Firefox Tracking Flags

(firefox65 affected, firefox66 affected, firefox67 affected)

Details

(Reporter)

Description

25 days ago

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 2

21 days ago

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.

Status: UNCONFIRMED → NEW
status-firefox65: --- → affected
status-firefox66: --- → affected
status-firefox67: --- → affected
Component: Untriaged → SVG
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → Desktop
Version: 67 Branch → Trunk

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?

Flags: needinfo?(longsonr)
Priority: -- → P3

(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.

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

You need to log in before you can comment on or make changes to this bug.