Re: The (new, enhanced) viewbox property

Hi Alex,

Thanks for your response.

(2013/12/17 11:14), wrote:
> On 2013-12-16 17:17, Brian Birtles wrote:
>> Hi all,
>> For SVG2 there are two proposed changes to viewBox.
>> a) Make it a CSS property so you can, for example, tweak it with media
>> queries to make responsive SVG images.
> Hi Brian-
> What are the use cases for (a) exactly? This seems to be mostly about
> convenience (not a bad thing).

An example of the use case is this graphic:

Resize it in your browser and you will see it changes aspect ratio 
accordingly. This is currently done using script but really should be 
able to be done declaratively since you could well want to do this for 
content loaded in contexts where script is disabled such as through the 
<img> element.

So it's not just convenience, but it actually lets you do things that 
are otherwise not possible.

> But the problem that I see is that
> whether the viewbox is defined in an attribute or in CSS, responsive SVG
> can currently only be made to work when width and height attributes are
> either omitted or supplied in percentages, and it seems like the
> majority of authoring tools typically include rootmost height and width
> attributes in pixels. So authors might well slap on a “viewbox:auto” CSS
> property, and then wonder why their svg isn’t responsive.
> The 1.1 intrinsic sizing spec says:
> “If either/both of the ‘width’ and ‘height’ of the rootmost ‘svg’
> element are in percentage units (or omitted), the aspect ratio is
> calculated from the width and height values of the ‘viewBox’ specified
> for the current SVG document fragment. If the ‘viewBox’ is not correctly
> specified, or set to 'none', the intrinsic aspect ratio cannot be
> calculated and is considered unspecified.[1]”
> So, to allow authors to force a hardcoded SVG to be responsive using
> pure css, it might be useful to add “auto” to this list of conditions,
> and also get rid of the use of percentage units as a indicator to force
> intrinsic ratio calculation (something that has never quite made sense,
> or been implemented consistently cross-browser) E.g. revise the above
> roughly to:
> “If either/both of the ‘width’ and ‘height’ of the rootmost <?> element
> are omitted, or if CSS width and height of the rootmost <?> element’ are
> both specified to the keyword ‘auto’, then etc etc… ”
> and then authors could write:
> .my-hardcoded-svg {
>    width: auto !important;
>    height: auto !important;
>    viewbox: auto;
> }
> and get instant responsive behavior without even having to open the svg
> file. :)

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.

> Also, while in this vein, would it also make sense to also port
> preserveAspectRatio to CSS, for some of the same reasons?

Yes, although I think we should probably try to harmonize with 
object-fit etc.[1] from CSS Images rather than have two properties that 
do similar things.

Best regards,



Received on Tuesday, 17 December 2013 03:14:39 UTC