Re: The (new, enhanced) viewbox property

Hi Alex,

I'm just going through this in order to try and summarise it for the 
next SVG telcon and I'm afraid I'm not quite sure I've understood your 
proposal.

(2013/12/21 11:22), alex@bellandwhistle.net wrote:
 > ...
> 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.

I don't quite understand this last sentence so let me try to summarise 
very briefly the interaction between CSS object-fit and SVG from my 
fairly very limited investigation.

As I understand it, while there is a lot of complexity, there are 
roughly two layers of sizing.

Firstly, CSS' object-fit sizing determines the concrete object size of 
the replaced content which is possibly different to the CSS box the 
replaced content is positioned into.

Secondly, SVG takes this concrete object size as the viewport into which 
it sizes the viewbox by applying preserveAspectRatio etc.

So, to take a concrete and somewhat complex example, I have a widget 
that may be displayed in a variety of different sized and shaped boxes. 
When it is squeezed into a vertical box I want it to maintain a portait 
aspect ratio and be centered in the box. When it is squeezed into a 
horizontal box I want a landscape aspect ratio.

For this use case, the default object-fit:fill ends up making the 
concrete object size the same as the CSS box (i.e. it doesn't query the 
SVG's aspect ratio at all) and this becomes the SVG viewport. Then in 
the SVG file we can use media queries to alter the viewbox and other 
properties to provide a graphic of the appropriate aspect ratio (and 
detail) and then preserveAspectRatio would provide the centering behavior.

A few observations:

1) Promoting preserveAspectRatio to a property here would make sense so 
that you could provide different stretching behavior and different sizes.

2) It seems easy to get into a loop here. If we had object-fit:contain, 
then the concrete object size would depend on the aspect ratio of the 
replaced content. But using the viewbox property in a media query would 
effectively make the aspect ratio of the replaced content depend on the 
concrete object size.

With the problem of loops aside, it appears this allows one to have a 
differently sized viewport (corresponding to the CSS box in this case) 
to viewbox and to even make that relationship dynamic.

Are there other cases where this is not possible (e.g. are you 
considering more standalong SVGs?) or have I completely misunderstood 
what you were referring to?

Thanks!

Brian

Received on Thursday, 9 January 2014 07:44:50 UTC