Inline SVG sizing in CSS


In an attempt to get some Web interoperability on inline SVG sizing, I
generated some tests to measure where we stand. Test runner:

Note that the expected results are aligned towards what Firefox and
Presto does. Blink/WebKit and IE does some things differently.

IE10 (10.0.9200.16384):

	Score: 76.34%
	Pass: 1113
	Fail: 345
Google Chrome (30.0.1599.0):
	Score: 78.40%
	Pass: 1143
	Fail: 315
Firefox* (27.0a1-dirty):
	Score: 100.00%
	Pass: 1458
	Fail: 0
Presto** (12.16):
	Score: 100%
	Pass: 1458
	Fail: 0

* Firefox currently makes it hard to measure the size of SVGs from
  script, due to mozilla bug 530985. I added a patch locally
  ( to be able to run the tests. You need
  this patch or something similar to reproduce my results.
** Presto doesn't fare well with the harness. Each individual test
   works, but when executed in the test runner harness some fail. I
   haven't investigated why.

Some observations based on manually investigating the results:

 * In Chrome, when omitting width and height attributes, 100%-values are
   propagated out to the CSS layout system in (to me) non obvious ways.
   This is a basic premise of the two following points.

 * Example: 0000-default_width_and_default_height.html

   An SVG with no width, no height and no viewBox. Chrome and IE gives
   100% width to SVGs even when they have no intrinsic ratio and default
   (lacuna) width attribute. Firefox and Presto falls back to 300px in
   this case.

   The relevant part of the spec CSS 2.1 10.3.2 says:

   "Otherwise, if 'width' has a computed value of 'auto', but none of
   the conditions above are met, then the used value of 'width' becomes
   300px. ..."

   So I think IE and Chrome does the wrong thing here, according to

 * Example: 0001-width_auto_and_height_through_width_and_ratio.html

   An SVG with no given width or height but with a viewBox and thus an
   intrinsic ratio.

   Firefox and Presto computes the width "from the constraint equation
   used for block-level, non-replaced elements in normal flow.", (see
   CSS 2.1 10.3.2 again) and the height from the calculated width and
   intrinsic ratio.

   Chrome gets the width correct but then also does the default 100%
   height thing and manages to pass the auto-height ancestor and resolve
   height against the grand-parent's height. Weird.

   IE gets the width correct as well but falls back to height 150,
   ignoring the intrinsic ratio.

   We haven't got much interoperability in the height here.

The other test results I've looked have been variations of the points
above, switching around width and height, etc... Also, see for how the test results are grouped by

I think the Firefox behavior (which Presto later borrowed from) were
born out of <>.
Comment #78 states that it hasn't been documented. Is this still true?

What I think basically came out of that bug and related work was to

 * not propagate default width and height 100% values out to the style

 * map explicit width and height attributes to the width and height CSS
   properties, so that percentage values can be handled according to CSS

 * remove any notion of percentage intrinsic size.

Feel free to correct me if I got any of that wrong. I think we should
get this spec'd somehow and ideally implemented in the other browsers.

Thoughts on this?


Received on Thursday, 10 October 2013 14:16:09 UTC