That chart is misleading. V8 supports (and has supported it for a long time) the vast majority of ES5. Since version 13 it's supported every ES5 features with the exception of Zero-width chars in identifiers, and I don't know when, but it was implemented somewhere between 16 and 23.
Yeah, Webkit support is disappointing. As mentioned in the article that is mostly because of a bug that prevents many effects from being rendered when used in an HTML document. Opening SVG files in a new window will render those effects correctly. But because no user will ever do that those effects are effectively broken.
Filters render just fine for me in embedded SVG files (I'm using direct embedding via <svg> tag in HTML5 documents). Not all primitives are fully implemented, but performance is definitely better than in Firefox. IE9 does not support filter effects at all, I don't see how WebKit is "lagging" here.
Awesome problem to solve (been looking for something similar without having to use three different tools), but there's no tutorial on how to use this or what it can do. Does it assume I've already assigned the glyphs in another piece of software or will it let me assign to characters if it can't tell?
It'd also be nice if there was a live specimen preview so I could adjust the ascent/descent visually. Also wish the weight was a drop-down that showed 100-900 and where the typical weights fall in e.g. 100 (Hairline)/ 400 (Regular) / 900 (Black).
Obviously you guys just built this thing two weekends ago, so those are just my two cents :)
Sort of. It implements a lowest-common-denominator vector stack on top of either VML for old-IE, or SVG for everything else. This means many vector operations available in SVG but not in VML are either not available in Raphael, or are implemented in a way that doesn't take advantage of native capabilities. We experienced an issue, for instance, with trying to animate a zoom effect on a path. This is doable in SVG with transform properties in a very performant way, but Raphael implemented it by recomputing all the path coordinates at each zoom level for each animation frame, which was too slow to be usable. On top of this, the other major browser environment that doesn't support SVG is pre-Honeycomb Android, which doesn't support VML either, so Raphael only gets you so far in terms of being cross-browser.
The data included in that table is totally wrong. Chrome supports most of the filter primitives defined in SVG spec, IE9 supports none of them, Firefox supports vast majority but with serious performance issues.
The real blocker for SVG is the lack of good authoring tools. Illustrator (used by the author of this article) apparently generates SVG files by rasterising many vector effects.
I suspect that there is a bug in WebKit that breaks bitmap rendering in certain circumstances, this would explain why some Illustrator-generated effects failed on Chrome.
The gradient mesh and drop shadow were exported as an embedded image by Illustrator, so it was never tried to do it via pure SVG.
But I guess the author doesn't have much experience with SVG's feature set and instead just fiddled around with Illustrator, looking at the export results and drawing conclusions for SVG.
There's a difference between "implemented" and "working".
Here's an example of the combination of PNG Transparence (in since version 1) and ShadowBlur (in for quite some time), both of which work on their own, but not in combination:
There are still lots of issues like this one, with limitless combinations of feature1, feature2, browser vendor to choose from that make working with vector graphics on the web several orders of magnitude more painful than simply throwing a .png up there and calling it done.
Most of the SVGs of this page don't test at all the described features, they're just PNGs or JPEGs embedded in SVG files. The author didn't even open its SVGs generated by Illustrator: a drop shadow in Illustrator does not mean a drop shadow in the generated SVG!
My experience is that SVG is simply not ready to support anything but the most basic vector art.
I'm never sure if it's Illustrator's SVG output, the format, or browser support that's lacking. But it's a total crapshoot if any kind of sophisticated techniques are going to make it out of AI. (Hell, it's a crapshoot if they'll make it through another PDF renderer, too; when I prep books for print, I just make a ton of TIFFs.)
Here's some other ways I might try to make that radial gradient in AI. And their results after eyeing the generated SVG.
- Draw about 8-10 lines in different colors radiating out from the central point. Make them into a blend. (This is an idiosyncratic use of the term "blend"; when you blend between two or more shapes, AI will draw a bunch of intermediary shapes that morph between them. You used to have to do this all the time before AI added the quick and easy gradient tool.)
This translates into SVG as a bunch of lines - SVG doesn't understand the concept of a blend, or at least AI's exporter doesn't, so six lines grouped into a blend become a hundred or so. It looks pretty good.
- Make a linear gradient; use a distortion mesh to turn it into a radial gradient. [1]
This translates into SVG as an embedded image. But it sure looks good.
- Draw about eight wedges. Blur them.
If I use AI's native blur, it turns into several embedded images. Also it's a bit pale as there are no 100% opaque pixels.
If I use an SVG blur, it's very compact - just a few blurred shapes. However, the rendering is just vile, with bounding boxes based on the edges of the polygons rather than ones expanded out to cover all that blur. Also it has the "no 100% opaque pixels" problem.
Also it's worth noting that Illustrator's UI for SVG effects is absolutely terrible; you've got a tiny list of cryptically named effects, and if you want to change the parameters you get to edit code.
- Finally, I revisited the line blend and turned those lines into long, thin wedges. Looks perfect. Translates into a whole ton of shapes.
I haven't tested file size. I suspect that it may not be a win over a bitmap until you get to like 1K pixels square.
Some of these results might be better if I was using Inkscape. If anyone would care to try doing similar things in that I'd be curious to see how well it fares on these methods - and on others you may come up with!
Yes, I can confirm that a lot of what your experiencing is Adobe CS's compromise with the SVG format, and indeed Inkscape is much better in this specific use case. In general, AI predates SVG, and in general is much broader in scope than SVG, especially with regards to integration with the rest of the suite, and blurring of the lines between illustration and photographic effects.
No not really, although if I was in need of some kind of option, I would explore a couple of things 1) Clipboard formats... like WMF on the clipboard into Inkscape 2) Printing as PDF or PS and then using Inkscape or Ghostscript to go from there... 3) See what kinds of options you get with obscure features of Photoshop like AI->Photoshop->Print as PDF ... in general I think for large complex drawings AI suffers from losing track of its own internal scene graph, or at least there are drawings and layers of effects that can suffer from the halting problem and just crash AI. I have seen several people in the creative coding and graph theory worlds struggle with this kind of problem regardless of tool. Best of luck to you!
Based off of the blog post previous to this one about the implementation of SVGs site-wide, I'm confused why they'd risk using SVGs over just CSS alone or CSS+PNGs or even matte'd GIFs? Maybe I'm behind the times, but that seems like a nightmare to maintain comparatively.
38 comments
[ 2.4 ms ] story [ 96.1 ms ] threadhttp://kangax.github.com/es5-compat-table/
http://caniuse.com/#search=svg
It'd also be nice if there was a live specimen preview so I could adjust the ascent/descent visually. Also wish the weight was a drop-down that showed 100-900 and where the typical weights fall in e.g. 100 (Hairline)/ 400 (Regular) / 900 (Black).
Obviously you guys just built this thing two weekends ago, so those are just my two cents :)
http://i.imgur.com/mH7dZ.png
As you can see, resized PNGs are not antialised at all in IE, but they a
The real blocker for SVG is the lack of good authoring tools. Illustrator (used by the author of this article) apparently generates SVG files by rasterising many vector effects.
I suspect that there is a bug in WebKit that breaks bitmap rendering in certain circumstances, this would explain why some Illustrator-generated effects failed on Chrome.
http://i.imgur.com/mH7dZ.png
As you can see, resized PNGs are not antialised at all in IE, but they are in Chrome.
"No problems so far. The SVG looks good in all modern browsers." Not so much.
- gradient meshes were never defined in SVG spec and none of the browsers supports them. This feature should be introduced in SVG 2
- WebKit-based browsers do support inner and outer glow effect (via combination of feGausianBlur, feFlood and feComposite filters)
- WebKit-based browsers do support drop-shadow effect (via feGausianBlur, feOffset and feMerge filters)
- WebKit-based browsers do support custom fonts (e.g. WOFF via @font-face, SVG fonts are dead)
- WebKit-based browsers do support linked and embedded images (using data:uri with base64 encoding)
- envelope distortion is not supported by any browser, SVG spec defines only affine transformations via transform attribute
But I guess the author doesn't have much experience with SVG's feature set and instead just fiddled around with Illustrator, looking at the export results and drawing conclusions for SVG.
Here's an example of the combination of PNG Transparence (in since version 1) and ShadowBlur (in for quite some time), both of which work on their own, but not in combination:
http://code.google.com/p/chromium/issues/detail?id=100703
There are still lots of issues like this one, with limitless combinations of feature1, feature2, browser vendor to choose from that make working with vector graphics on the web several orders of magnitude more painful than simply throwing a .png up there and calling it done.
<svg xmlns="http://www.w3.org/2000/svg xmlns:xlink="http://www.w3.org/1999/xlink class="tributary_svg"><rect width="200" height="200" x="100" y="100" fill="#1A9224"></rect><image width="200" height="200" xlink:href="https://twimg0-a.akamaihd.net/profile_images/2560186719/7f57... x="325" y="100"></image></svg>
d3 code to generate this http://enjalot.com/tributary/3747523/
For example, look at the source of the "mesh" test, it's a beautiful embedded base64 PNG: http://voormedia.com/blog/2012/10/creating-svg-vector-graphi...
I'm never sure if it's Illustrator's SVG output, the format, or browser support that's lacking. But it's a total crapshoot if any kind of sophisticated techniques are going to make it out of AI. (Hell, it's a crapshoot if they'll make it through another PDF renderer, too; when I prep books for print, I just make a ton of TIFFs.)
Here's some other ways I might try to make that radial gradient in AI. And their results after eyeing the generated SVG.
- Draw about 8-10 lines in different colors radiating out from the central point. Make them into a blend. (This is an idiosyncratic use of the term "blend"; when you blend between two or more shapes, AI will draw a bunch of intermediary shapes that morph between them. You used to have to do this all the time before AI added the quick and easy gradient tool.)
This translates into SVG as a bunch of lines - SVG doesn't understand the concept of a blend, or at least AI's exporter doesn't, so six lines grouped into a blend become a hundred or so. It looks pretty good.
- Make a linear gradient; use a distortion mesh to turn it into a radial gradient. [1]
This translates into SVG as an embedded image. But it sure looks good.
- Draw about eight wedges. Blur them.
If I use AI's native blur, it turns into several embedded images. Also it's a bit pale as there are no 100% opaque pixels.
If I use an SVG blur, it's very compact - just a few blurred shapes. However, the rendering is just vile, with bounding boxes based on the edges of the polygons rather than ones expanded out to cover all that blur. Also it has the "no 100% opaque pixels" problem.
Also it's worth noting that Illustrator's UI for SVG effects is absolutely terrible; you've got a tiny list of cryptically named effects, and if you want to change the parameters you get to edit code.
- Finally, I revisited the line blend and turned those lines into long, thin wedges. Looks perfect. Translates into a whole ton of shapes.
I haven't tested file size. I suspect that it may not be a win over a bitmap until you get to like 1K pixels square.
Some of these results might be better if I was using Inkscape. If anyone would care to try doing similar things in that I'd be curious to see how well it fares on these methods - and on others you may come up with!
Reference JPG: http://i.imgur.com/ZSDAZ.jpg Source AI and generated SVG: http://www.sendspace.com/file/rn83zw
[1] Tutorial here: http://vector.tutsplus.com/tutorials/tools-tips/quick-tip-cr...
If you load them directly into Chrome, the SVG renders fine. http://voormedia.com/blog/2012/10/creating-svg-vector-graphi...
Maybe this has something to do with Chrome's process of rendering this as a bitmap? (Random guess)
I haven't tested any others, but I strongly doubt the author did either.