SVG background-images with preserveAspectRatio='none' render differently to Chrome/WebKit

NEW
Unassigned

Status

()

Core
Layout: Images
6 months ago
2 months ago

People

(Reporter: Thomas Wisniewski, Unassigned)

Tracking

unspecified
Points:
---
Bug Flags:
webcompat ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: webcompat, URL)

Attachments

(2 attachments)

(Reporter)

Description

6 months ago
Created attachment 8870854 [details]
testcase.html

Chorme/WebKit appear to render SVG background-images with background-size:contain as Firefox does when background-size:100% 100% is used instead (that is, Firefox does not stretch them vertically the same way). Compare the attached testcase in both browsers for a quick example (note that Edge did not seem to render the SVG at all when I just tried it).
Flags: webcompat?
(Reporter)

Comment 1

6 months ago
Actually, I'm unsure if it's specific to SVGs. I just tried replacing the data-url with a 2x2 pixel PNG and it might also be showing the same rendering-difference:

background-image:url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAIAAAD91JpzAAAAFUlEQVQI1wXBAQEAAACAEP9PF1CpMCnkBftjnTYAAAAAAElFTkSuQmCC");
(Reporter)

Comment 2

5 months ago
Jet, is this something we should triage soon?
Flags: needinfo?(bugs)
(Reporter)

Comment 3

2 months ago
dholbert, what do you think about this one?
Flags: needinfo?(dholbert)
This seems interesting, though I'm not sure this has anything to do with "background-size:contain".

With the testcase as well as the original URL ( http://www.makeuseof.com/service/linux/ ), the rendering doesn't seem to be impacted by the "background-size:contain" styling.  Neither Firefox nor Chrome change their behavior if I uncheck that style in devtools.

Maybe that's different depending on DPI or some other system metric, though -- could you confirm whether "background-size:contain" really makes a difference here?
Flags: needinfo?(dholbert) → needinfo?(wisniewskit)
Created attachment 8905615 [details]
testcase 2
Facts about testcase 2:
* We draw three short dark triangles on "testcase 2" (32px tall each).
* Chrome and Edge only draw one tall triangle (100px tall, the full height of the div).
* THOUGH: if I remove preserveAspectRatio='none' from the SVG image, then Edge & Chrome change to match us.  (and our rendering doesn't change.)  So it seems that attribute influences their calculation of the image's height, when they decide how to tile it.

The Chrome/Edge behavior seems odd to me -- IIRC preserveAspectRatio is only supposed to influence *whether* an image is stretched/skewed when rendered to a given viewport. And in this case, when preserveAspectRatio is omitted, Chrome/Edge seem to agree with us that the viewport for each image-repetition is only about 1/3 the height of the div. But they change their mind about the viewport size if preserveAspectRatio='none' is provided.

In other words: IIUC, preserveAspectRatio is only supposed to take effect *after* a viewport has been decided on (and then influences how the SVG content scales to fit that viewport).  But in this case, Chrome/Edge seem to be letting it influence the actual decision about how big the viewport itself should be (or "viewports", really, since the image gets tiled).

https://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute

Anyway -- at this point, given just one known affected site and not super-serious breakage, I'm not inclined to worry about this too much, though perhaps we should file a Chrome/Edge bug (and perhaps find out via that bug if they have any spec justification for their behavior).
(Reporter)

Comment 7

2 months ago
I agree with your assessment. Clearing the needinfo.
Flags: needinfo?(wisniewskit)
Flags: needinfo?(bugs)
Summary: SVG background-images with background-size:contain render differently to Chrome/WebKit → SVG background-images with preserveAspectRatio='none' render differently to Chrome/WebKit
You need to log in before you can comment on or make changes to this bug.