Proposal: Promote SVG Viewbox to a CSS property, extend to all transformable elements

[tabatkins]

From @vidhill on May 19, 2016 14:0

First, original proposition, https://lists.w3.org/Archives/Public/www-svg/2013Dec/0080.html

Yes, I'm trying to bring this to the table again as it did not seem to get much attention/discussion the last time around.
-maybe being on Github will be more conducive to discussion..

I really agree with this proposal,
being able to modify the viewbox on a SVG element using CSS would allow for very useful applications of SVG in a responsive layout, (See Sara Soueidan's examples below)

Sara Soueidan has a very good article demonstrating a perfect need and use cases for this here: https://sarasoueidan.com/blog/svg-art-direction-using-viewbox/

There were some enthusiastic responses from some SVG heads..

@sdras Sarah Drasner Mail List Reply

@AmeliaBR Amelia Bellamy-Royds Mail List Reply

@jakearchibald Jake Archibald Mail List Proposal

Copied from original issue: w3c/csswg-drafts#128

[tabatkins]

Yup, sorry about the request getting buried. I got swamped for a while and am trying to catch up on proposals.

Yes, viewbox should totes be a property; nearly everything in SVG should be. A simplified version that solely exposes none | <length>{4} would be utterly uncontroversial. I like, however, the bounds value, and having it be defined simply as the stroke bounding box is good. This is essentially just CSS shrinkwrapping (in theory, of course; it's different in practice).

[tabatkins]

From @AmeliaBR on May 24, 2016 21:11

@tabatkins Are you able to move this issue to the FX repo? I'd like to keep any view-box spec under the (shared) responsibility of the SVG WG.

And if you do start drafting something, Tab, I'd be happy to review it. If you don't get to it, it's still on my eventual To-do list. Just buried under far too many other to-do's!

[tabatkins]

From @bradkemper on May 25, 2016 13:46

Would this affect non-SVG stuff too? I'm no expert on this attribute, but it sounds kind of like a clip-path:inset() effect which also affects the element's instrinsic dimensions, causing it to be scaled so that the new dimensions are contained by the original dimensions. Is that something we want for plain old HTML too?

[tabatkins]

@bradkemper I don't think so. This doesn't clip, either; viewBox just (a) from the POV of stuff inside the SVG, sets up the coordinate space they position themselves in (and in particular, what "100%" maps to), and (b) from the POV of stuff outside the SVG, defines the intrinsic aspect ratio of the element.

(a) doesn't mean anything for non-SVG elements. (b) could theoretically, but it's a very roundabout way to handle aspect ratio, and misses some features we'd like for a real aspect-ratio property, so I don't think we should try to smuggle aspect-ratio into general CSS via viewbox.

[BigBadaboom]

Animatable: as simple list of length

Is this flexible enough? Or should viewBox perhaps be considered a shortcut for

viewbox-x viewbox-y viewbox-width viewbox-height

[tabatkins]

You can't specify those independently in SVG, and to the best of my knowledge people haven't asked for it (despite the handful of examples I've seen of viewBox animating), so I'm inclined to not do that unless there are good use-cases for it.

[AmeliaBR]

@BigBadaboom

I suggested making the min-x and min-y parts optional (default to 0), but I don't see any need for breaking it into shorthand & longhand properties.

And yes, it should be animatable as a list of 4 independent numbers. Being able to animate a viewBox with CSS animations/transitions is one of the main benefits for SVG of upgrading it to a property. (The other main benefits being media queries and assigning a single viewBox to a class of inline SVG icons.)

[AmeliaBR]

@bradkemper

For non-SVG content, the viewBox would:

• Allow any content to scale to fit available space (e.g., fancy text headings, HTML poster ads).
• Define an aspect ratio that could be used to reserve the correct height/width for embedded content (videos, images that haven't downloaded yet) in a responsive design.

I'm not sure how this relates to clip-path.

[sdras]

+1 on animatable, I think part of the reason it has only been done a handful of times is undereducation. It has a lot of nice implications for the web and informative graphics. 4 independent numbers makes a lot of sense. Thank you for all of your work, Tab!

[BigBadaboom]

My thought was that if animators wanted to use viewBox like a camera, they may want to animate position differently from size.

If it is an array of lengths, they could achieve that to some extent with @Keyframes. But I was thinking they may want to do something like:

.crash-zoom {
  viewbox-x: 100;
  viewbox-y: 100;
  viewbox-width: 16;
  viewbox-height: 9;
  transition: viewbox-x: 0.5s easeInQuad, viewbox-y: 0.5s easeInQuad,
              viewbox-width: 0.5s easeOutElastic, viewbox-height: 0.5s easeOutElastic;
}

[AmeliaBR]

@BigBadaboom I can see the use-case. But it's something that could be easily added in after the fact, so we don't have to worry about it now. Once we get authors are really using the property as is, then they can tell us if it isn't flexible enough without shorthand/longhands.

[vidhill]

+1 on animatable as well,

Great creative potential on animated viewbox.

Great to see this being discussed.

[jezmck]

+1

[bodymovin]

+1