Re: Inline SVG sizing in CSS

On Oct 10, 2013, at 4:13 PM, David Vest <davve@opera.com> wrote:

> 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?

Did you test a combination of 'with'/'height' properties to attributes on the <svg> element? We have a resolution that both shall be treated as presentation attributes. So one overrides the other. How does that preform in different browsers?

Greetings,
Dirk
 
> 
> David
>

Received on Thursday, 10 October 2013 14:50:26 UTC