Re: The (new, enhanced) viewbox property

On 2013-12-16 19:14, Brian Birtles wrote:

> That's an interesting idea. If we introduce a new top-level <graphics>
> element I would be interested in simply removing width/height from its
> definition for similar reasons.


Thanks Brian, I initially had the same thought, but on reflection have 
come to the opposite conclusion: I think the spec should retain width 
and height attributes in order to calculate intrinsic viewport aspect 
ratios.

The elephant in the room is that the spec doesn’t distinguish between 
the intrinsic sizing of an SVG viewport, and the intrinsic sizing of a 
viewbox. These are actually completely different things, which the spec 
(written long before the heyday of responsive design, let alone 
object-fit) confusingly treats as one. (They can of course be 
numerically equal.) When object-fit has sunk into everyone’s heads a bit 
more I think this will suddenly become obvious all around. Object-fit 
doesn’t yet tackle the question of the viewbox. It only concerns the SVG 
viewport and its container. The SVG spec says for the intrinsic sizing 
of the viewport to derive from the intrinsic sizing of the viewbox when 
an dimension attribute value is missing, or supplied in percentage 
units, but the two aspect ratios are still essentially different, and 
they ultimately have different use cases in layout. When object-fit asks 
for the intrinsic ratio of an SVG viewport, it will be tempting but 
wrong to hopscotch over the viewport ratio and pass the viewbox ratio. 
That distinction needs to be specc'ed.

I understand the appealing simplicity of throwing out height and width 
attributes completely for a new element, and punting all rootmost 
viewport sizing to CSS, but I also don’t think that preserves the 
meaning of the word “intrinsic” for a rootmost viewport. CSS sizing is 
arguably never “intrinsic” in the sense of "natural". And it doesn’t 
preserve the possibility of different aspect ratios for the viewport and 
the viewbox, which object-fit requires in order to work properly as 
written.

More generally, I think there needs to be a simultaneous breakthrough in 
the spec in terms of both viewport sizing and viewbox sizing, and their 
relationship. They need to be distinguished, but harmonized, without 
simply pointing at each other in a circular fashion. I’ll try to 
summarize:

One problem is that numeric percentage values apparently have no 
semantic meaning for rootmost svg. Is there ever a case according to 
spec in which rootmost:

<svg width=“100% height=“100%”>

is handled differently from

<svg width=“50% height=“50%”>

or even

<svg width=“0.01% height=“0.01%”>

Because these all have the same intrinsic dimensions (none, no viewbox), 
CSS specified size (none), and same default object size, the viewports 
should all render identically. Quick test:

http://jsfiddle.net/CYLjW/

No browser renders the “0.01” case, which I would argue is technically a 
bug. 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.
-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?
-IE11 renders the viewports all overlapping, and very badly broken.
-Opera 12 renders the width of the second rect in #3 at a different 
size, but leaves the first the same (?).

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

I think the problem here is in the spec, not with broken implementations 
per se. Without going into great detail, there is a circularity[1] where 
non-percentage dimensions are being defined to specify intrinsic aspect 
ratios, and intrinsic aspect ratios are referencing dimensions, with 
neither part of the specification actually yielding what we need: a 
step-by-step algorithm to determine rootmost viewport dimensions.

As a further complication, since 100% is currently the lacuna value for 
both height and width, browsers have to consider whether that percentage 
value is coming from an explicit stated attribute, a UA stylesheet, or 
some other internal value. This seems another part of the recipe for the 
existing confusion.

Here are some compromise possibilities to address some of these issues 
short of a new <graphics> element:

- For rootmost SVG and <graphics>, only accept width and height 
attribute values in user units. Physical sizing (em,mm,px) can be done 
in CSS. Disallow percentage values for rootmost element attributes. 
Percentages don’t yield an independent intrinsic ratio for the viewport. 
There will be no breakage, because an invalid dimension attribute will 
simply instruct the browser to derive aspect ratio from the viewBox, if 
supplied. This would clarify things, and there’s no meaningful current 
compatibility to break.

- The lacuna value for rootmost svg dimensions could be “auto”, not 
100%. This could be further defined in terms compatible with css. We 
ought to get away from percentages entirely for the rootmost case, 
because the numbers aren’t defined to be meaningful, and because there 
is an understandably strong tendency on the part of both browsers 
(Webkit) and authors to understand them in terms of the containing 
block.

- A detailed algorithm for generating rootmost viewport dimensions needs 
to be written, similar to that already existing for replaced content in 
HTML, that harmonizes with the elegance of object-fit, and specifies SVG 
default object size.

- nit: standardize on either “outermost” or “rootmost” and use either 
one or the other consistently across the spec. I'm using rootmost out of 
habit but don't have a strong preference.

Cheers,
Alex

[1] https://svgwg.org/svg2-draft/single-page.html#coords-IntrinsicSizing

Received on Saturday, 21 December 2013 02:23:14 UTC