Re: The (new, enhanced) viewbox property

alex@bellandwhistle.net writes:

> ... But besides that, results in current browsers are all over the
> place:
>
> -Chrome Canary renders the <rect>s all at the same size, but the
> containing viewports are all different sizes. This is an old,
> longstanding bug.

Not sure what you mean by "but the containing viewports are all
different sizes" but this is how I see it for Chrome:

WebKit and Blink based browsers has the notion of "percentage intrinsic
size". This roughly means that the percentage values contribute to the
SVG size ("containing viewport"). As you know, 100% is the default value
for width and height and the sizes will be the be the following:

#1: 100% x 100%
#2: 100% x 100%
#3: 50% x 50%
#4: 0.01% x 0.01%

Then all these are resolved using the document viewport size. So why is
that?

Since Blink and WebKit browsers doesn't go through the style system,
there are differences in how the percentage values are resolved. Compare
the inline-block with an <svg> in the following snippet:

 <!doctype html>
 <style>
   div, svg { outline: 2px dashed black; margin: 0.5em; }
 </style>
 <div style="display: inline-block; height:100%; background: blue; width: 100px"></div>
 <svg height="100%" style="background: green; width: 100px"></svg>

<svg> resolves 100% height to the document viewport height, while the
<div>'s height is resolved against the <body> with height:auto and
collapses to zero. This "quirk" applies to your tests as well and
explains why Chrome Canary uses the document viewport to resolve the
percentage values.

> -Firefox Aurora renders the <rect>s in #1, #2, #3 all at different
> widths (but the same height). Since none of these have a viewBox, and
> 100% is the lacuna height/width value, shouldn’t the viewports of
> examples #1 and #2 match?

Firefox instead maps width and height attributes to the corresponding
style properties. Two major differences compared Chrome boils down to:

 * it doesn't map the default values* to style.

 * percentages values take part in normal css calculations.

In your examples we get:

#1: 300x150 (fallback size)

#2: 100% x 100% -> 100% x 150 (fallback height since 100% height can't
    be resolved since <body> height depends on children)

#3, #4: same as #2 but with different percentage value.

> -IE11 renders the viewports all overlapping, and very badly broken.

I haven't investigated what IE does. Would be interesting to know.

> -Opera 12 renders the width of the second rect in #3 at a different 
> size, but leaves the first the same (?).

Opera 12 should render your examples the same as Firefox, AFAIK.

> In short: zero compatibility. And this is just one example.

Yes, this isn't very impressive.

David

Received on Monday, 23 December 2013 10:45:36 UTC