Closed Bug 1688968 Opened 4 years ago Closed 3 years ago

use of svg viewbox is inconsistent

Categories

(WebExtensions :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 700533

People

(Reporter: mixedpuppy, Unassigned)

References

Details

Apparently it is not uncommon to use viewbox in an svg rather than width/height, and this works in some APIs but not all APIs. In bug 1688492 it is pointed out that you must use width/height for an svg used with notifications.

We should find out if this is accurate (i.e. it is very common to use viewbox, and it works in some APIs), why this limitation exists and if it is intentional. If it is not intentional, we should probably fix this and allow viewbox to be used consistently across all APIs that accept svg.

viewBox and width/height are orthogonal things. viewBox is about the internal canvas co-ordinates. width/height is the size of that canvas.

The default (lacuna) values for width/height are 100%. That works when you put SVG on a web page because it's 100% of the browser's canvas. It works less well in some other circumstances e.g. if you draw to a canvas because canvas doesn't really have a size.

Our current implementation is intentional but the specifications are unclear and Chrome does work a little differently.

When embedded in an object or iframe the spec for replaced elements says if you can't determine the size of the object or iframe, use 300px x 150px. Chrome and Firefox both do that. They both use the viewBox to define an aspect ratio so you can end up with something other than 300 x 150px if you have a viewBox.

If you're not in a replaced element though the specs are silent. Chrome still uses 300px x 150px, Firefox doesn't display anything.

Thank you Robert for the excellent explanation.

I'm close to inclined to close this bug also, but wonder if we don't display for technical issues or if it's just an oversight. Is it more common for svg files to have height/width or not? If the most common case is not, it may still be worth fixing any instances we run into.

Depends on what tools you use to create them and what buttons you press with those tools. Seeing height and width is probably more common than not seeing them but they are often set to 100% because the most common use cases for SVG are to be embedded in a webpage or displayed directly in a browser and in those circumstances 100% makes a lot of sense.

If you use a tool it either has to ask you what you want to do with the SVG when you've finished with it or guess.

Severity: -- → S3
Priority: -- → P5

I have often only used viewBox in my SVGs, and have several times experienced weird bugs in Firefox that were hard to diagnose, and eventually forced me to use Chrome for that project instead. I now know that all these bugs were caused by the lack of a width/height in my images.
IMO it is problematic that some parts of Firefox accept SVGs that only have viewBox (<img> for example), while other parts don't (<canvas> for example). This inconsistency is what made it so hard for me to diagnose the issue.

I think that these images should either be categorically rejected by Firefox or categorically supported. And since all other browsers support them, categorical support seems to me like the only feasible way to go.

I have just posted a bug for a real-world issue where this caused some site functionality to break: https://github.com/webcompat/web-bugs/issues/101816
I also made a little test suite to show how inconsistent SVG handling is across browsers, in case it is useful: https://codepen.io/atjn/full/GRyMWvZ

Isn't that partially a duplicate of Bug 1521882?

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.