Open Bug 1367461 Opened 5 years ago Updated 8 months ago

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

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

defect
Not set
normal

Tracking

()

Webcompat Priority P3

People

(Reporter: wisniewskit, Unassigned)

References

()

Details

(Whiteboard: webcompat)

Attachments

(2 files)

Attached file 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?
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");
Jet, is this something we should triage soon?
Flags: needinfo?(bugs)
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)
Attached file 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).
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
Flags: webcompat?
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Webcompat Priority: --- → ?
Webcompat Priority: ? → P3
You need to log in before you can comment on or make changes to this bug.