- From: David Vest <davve@opera.com>
- Date: Thu, 10 Oct 2013 16:13:53 +0200
- To: www-svg@w3.org
Hi! In an attempt to get some Web interoperability on inline SVG sizing, I generated some tests to measure where we stand. Test runner: http://people.opera.com/davve/resources/test-runner.html 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 (http://pastebin.com/NV505TVn) 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 spec. * 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 http://pastebin.com/cTfP1EnA for how the test results are grouped by browser. I think the Firefox behavior (which Presto later borrowed from) were born out of <https://bugzilla.mozilla.org/show_bug.cgi?id=668163>. 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 system. * map explicit width and height attributes to the width and height CSS properties, so that percentage values can be handled according to CSS rules. * 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? David
Received on Thursday, 10 October 2013 14:16:09 UTC