In terms of web design, it usually expresses advanced adapting to different breakpoints/screen sizes, but it's difficult to draw the line where something stops being a regular responsive design and starts being artistically directed.
In the context of this article, it's about cropping images (e.g. you could have a full-body shot of the company CEO on the desktop version of your page and then just crop the face for mobile). One can already achieve the same effect in modern browsers using the picture element, although the cropped versions of images need to be prepared in advance.
I have been busy contracting for a client, building a product configurator based on SVG. It feels like I'm working with a better version of Flash, but with much slower rendering.
SVG in the browser is much more extensive than I had realised. There's really a lot you can do with it, and that kind-of snuck up on me. I've never had to touch SVG, been using canvas and DOM elements for a great many things. And now, all of a sudden, there is this massive part of the browser that I had neglected, where you can do anything.
If you work with designers that use Illustrator, you can really create a efficient workflow with SVG as a base.
Flash is slow. In-browser animations using 'HTML5' (as in full cartoon animations) as well as SVG manipulations is quite a bit slower than Flash. Always has been. Will be for a bit longer.
For vector animation, as well as optimised bitmap animations Flash was blazing fast and GPU accelerated. Granted the plugin in general was bloated, and lots of Flash objects on a page slowed your browser down, but once it got going (for example in a full screen game or whatever) Flash was very efficient. I'd say the web platform has not yet caught up.
A big part of that is likely down to the fact that while static SVG rendering works just fine, the dynamic side of it hasn't got the same amount of love.
Maybe as SVG gets more traction, we'll see browsers improve in that regard.
An alternative solution to a viewbox property would be to use CSS transforms. It is a bit harder to work with, since you have to specify translation and scale instead of simply specifying the bounding box, but I don't think it is unreasonably hard.
Rather than converting viewbox-style bounds coordinates into translate/scale property values, it's probably better to use the matrix property (which is also part of CSS transforms).
The math is trivial, and the transformation matrix is conceptually much more powerful. You can start out with just the 2D zoom effect shown here, and then add rotation and even 3D transformations later while still using just one matrix.
(Full disclosure: contributor) We went with transforms for the svg-pan-zoom library [0], but it's interesting to compare using transforms vs. the viewBox [1].
Sorry to say but people are completely missing the point. Before I get into the viewBox, let me quickly address some other comments.
If you are having performance hits with SVG you are using it wrong. It's like developing a video console game for the first time without any prior knowledge to video game development, memory techniques, asset loading, and so on...you will make a shitty boated game. 99% of active web developers & designers mis-understand SVG under the hood so don't be surprised if you can't find one predominant example of SVG in production.
In regards to the viewBox, what is its purpose? It is there to keep content in proportion. But why? why is the viewport not the viewBox?
Because the viewBox was created around 1999 when computers were slow and SVG was also heavy and slow. The viewBox had two apparent agendas, i) To reduce scaling of content, that would require more calculations to render ii) To be more in-line and proportionate to CSS. Because CSS in 1999 looked terrible on high res monitors.
The viewBox was a way to downgrade SVG for practical use back then, but the beauty of it is that it can be tweaked to behave in a full screen scalable fashion. This is why SVG is more desirable for the future.
So no, the ViewBox solves nothing in CSS, SVG is an amazing technology that people refuse to understand because they don't want to think too much.
SVG is not actually slower than canvas, if you see two equivalent examples of SVG and canvas the canvas may seem faster but that's because it can not do as much. If you now try to add multiple events to animated element SVG will perform faster.
People need to stop the obsession with CSS and learn SVG so vendors can improve the performance, spec and so we can make shit look good on the web!
You don't need to be a "computer scientist" to understand vector based graphics are the future of the web.
The only purpose of the viewBox attribute is to define a rectangular area in the abstract coordinate system.
How that area will be fit into the viewport is determined by the "preserveAspectRatio" attribute.
If you don't define any viewBox then there will be no scaling - 1px in the viewport coordinate system will be mapped to 1 user unit in the abstract initial user coordinate system.
16 comments
[ 2.1 ms ] story [ 40.3 ms ] threadIn the context of this article, it's about cropping images (e.g. you could have a full-body shot of the company CEO on the desktop version of your page and then just crop the face for mobile). One can already achieve the same effect in modern browsers using the picture element, although the cropped versions of images need to be prepared in advance.
SVG in the browser is much more extensive than I had realised. There's really a lot you can do with it, and that kind-of snuck up on me. I've never had to touch SVG, been using canvas and DOM elements for a great many things. And now, all of a sudden, there is this massive part of the browser that I had neglected, where you can do anything.
If you work with designers that use Illustrator, you can really create a efficient workflow with SVG as a base.
How much slower? Flash is slow enough as it is. I can't imagine using something even slower.
Maybe as SVG gets more traction, we'll see browsers improve in that regard.
I really like SVG. But because of some performace issues, I sometimes think I want to recreate the rendering engine in Canvas.
See for example: https://jsfiddle.net/kuvodbax/1/
The math is trivial, and the transformation matrix is conceptually much more powerful. You can start out with just the 2D zoom effect shown here, and then add rotation and even 3D transformations later while still using just one matrix.
[0] https://github.com/ariutta/svg-pan-zoom/blob/f84567bae1b80ac... [1] https://msdn.microsoft.com/en-us/library/gg589508%28v=vs.85%...
If you are having performance hits with SVG you are using it wrong. It's like developing a video console game for the first time without any prior knowledge to video game development, memory techniques, asset loading, and so on...you will make a shitty boated game. 99% of active web developers & designers mis-understand SVG under the hood so don't be surprised if you can't find one predominant example of SVG in production.
In regards to the viewBox, what is its purpose? It is there to keep content in proportion. But why? why is the viewport not the viewBox?
Because the viewBox was created around 1999 when computers were slow and SVG was also heavy and slow. The viewBox had two apparent agendas, i) To reduce scaling of content, that would require more calculations to render ii) To be more in-line and proportionate to CSS. Because CSS in 1999 looked terrible on high res monitors.
The viewBox was a way to downgrade SVG for practical use back then, but the beauty of it is that it can be tweaked to behave in a full screen scalable fashion. This is why SVG is more desirable for the future.
So no, the ViewBox solves nothing in CSS, SVG is an amazing technology that people refuse to understand because they don't want to think too much.
SVG is not actually slower than canvas, if you see two equivalent examples of SVG and canvas the canvas may seem faster but that's because it can not do as much. If you now try to add multiple events to animated element SVG will perform faster.
People need to stop the obsession with CSS and learn SVG so vendors can improve the performance, spec and so we can make shit look good on the web!
You don't need to be a "computer scientist" to understand vector based graphics are the future of the web.
How that area will be fit into the viewport is determined by the "preserveAspectRatio" attribute.
If you don't define any viewBox then there will be no scaling - 1px in the viewport coordinate system will be mapped to 1 user unit in the abstract initial user coordinate system.