SVG can do that?(slides.com)
slides.com
SVG can do that?
http://slides.com/sdrasner/svg-can-do-that#/
201 comments
It's such a shame that XSLT has such a poor image - v1.0 was troublesome for sure, but the modern language is remarkably flexible, expressive and elegant, as long as you leave your procedural baggage at the door.
It's not without its wobbly bits, but show me a language that isn't.
It's not without its wobbly bits, but show me a language that isn't.
I should probably admit that I really like XSLT (perhaps I'm insane too), but it was really unsuited to the task we were using it for. I've since done quite a bit of XSLT and it's definitely the main tool I'd use if I wanted to screen scrape some HTML, for instance. But can you imagine someone saying "We want you to draw paths between points and they can't cross. And we want you to do it in XSLT"? I mean, you can do it... but... "not fun" doesn't begin to describe the pain.
I used XSLT on a project. I came from a functional mindset. XSLT is terrible and deserves its poor image.
SOAP, RDF and the semantic web clique, and other monstruosities of the 2000s gave XML a bad name but XSLT is nice. Indeed it would have been a nicer solution than responsive css to tackle the challenges of mobile devices.
I've done quite extensive XSLT development and like it for particular tasks, but I think XSLT's weak points are
1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project
2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).
XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project
2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).
XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
Amen. And while we're at it, let's throw some of the credit to XPath. Wouldn't you like concise, declarative traversal for your data structures? (Yeah, I'm sure somebody's already built it.)
I don't think I agree about responsive css, but that's another discussion.
I don't think I agree about responsive css, but that's another discussion.
I experiment with using XPath selectors to apply styling :D Can reach many things CSS selectors arent designed to reach!
I ended up writing a full compiler stack in XSLT for declarative, XML-based DSLs[0][1] and a few targets (mainly JavaScript and HTML). It didn't start out as that, but having already written basic HTML/JS generation from a simple DSL, it evolved from there.
It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.
If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.
And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.
[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/
It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.
If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.
And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.
[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/
I guess I'm dumb, but I have no idea what 'PGM' is supposed to mean in this context.
I'm guessing Program Manager, which is new-corporate speak for Project Manager.
The abbreviation suggests that it's Pro Gram Manager. As opposed to, say, an Amateur Ounce Manager.
Yes. Exactly. I can't remember what we actually called them at the time (in polite company).
Project Manager - Writes specs and documentation for individual features.
Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.
Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.
Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.
Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.
Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.
Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.
Program Manager[1]. i.e. too many generals and not enough soldiers
1: https://en.wikipedia.org/wiki/Program_management
1: https://en.wikipedia.org/wiki/Program_management
I have no idea what half of that comment means (I'm not a programmer) so you aren't alone! (No insult meant to the original commenter!)
Yeah, sorry. It's terribly unclear :-) Basically there is a kind of markup called XML. You can define arbitrary hierarchies with it. It's very similar in shape to HTML (and at one point there was a big push to make HTML a subset of XML, but it failed). SVG is a graphics format that is defined in XML.
XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).
We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.
None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.
The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.
We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).
Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).
At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.
Hope that was more understandable/informative!
XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).
We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.
None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.
The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.
We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).
Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).
At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.
Hope that was more understandable/informative!
Great times indeed. I did map-rendering and later (limited) map editing with SVG, XSLT and python 15 years ago. I even had something that resembled AJAX/REST in my stack, but that was not named in that way back then. I really learned a lot, even if some of it was as crazy as your thing.
Or, for the slightly more insane approach we (and by that I mean people in my organisation prior to my arrival) decided that XSLT was the right tool to transform XML to Python. XML to XML sounds like a walk in the park after that. :)
This showcases what's wrong with SVG: It does way too much!
To be useful as a vector image format, there should be strict rules (and less cruft). Why is there no libsvg like libjpeg or libpng? Why have interaction as part of an image format?
SVG lives in an uncanny valley between jpeg and flash/js.
I think there is still a big need for a real vector interchange and display format. Right now people pick a "good" subset of SVG. Or even fallback to fonts.
My dream vector format:
- Pixel perfect across implementations at 50%,100%,200% renderings. At least grid aligned lines.
- Lossless roundtrip across apps. Start in Illustrator, edit parts in Inkscape, other parts in Animate, untouched things stay exactly the same.
- Standard zero dependency C reference implementation: Stream in, bitmap out.
To be useful as a vector image format, there should be strict rules (and less cruft). Why is there no libsvg like libjpeg or libpng? Why have interaction as part of an image format?
SVG lives in an uncanny valley between jpeg and flash/js.
I think there is still a big need for a real vector interchange and display format. Right now people pick a "good" subset of SVG. Or even fallback to fonts.
My dream vector format:
- Pixel perfect across implementations at 50%,100%,200% renderings. At least grid aligned lines.
- Lossless roundtrip across apps. Start in Illustrator, edit parts in Inkscape, other parts in Animate, untouched things stay exactly the same.
- Standard zero dependency C reference implementation: Stream in, bitmap out.
This! I've started to look for usable vector image format for game development somewhere in 2004, now it's 2017 and there is still nothing available. For SVG you literally need to pull-in whole browser engine, which is most likely 2-3 times the size of your whole game.
One possible solution is to the same what XMPP did on XML, or JSON did on JavaScript: Define a "safe subset" of SVG, and stick to that. Perhaps use the "safe subset of XML" as a base (as defined e.g. in XMPP.)
Use a library (or at least a validator) that works exactly on this subset, and fails for anything not strictly conforming to this.
Of course, this is not as satisfying as a "clean slate" approach, but on the other hand, this is a clear migration path with backwards compatibility - which is always good to have during a transition period to avoid all those bootstrapping and chicken-egg issues.
Use a library (or at least a validator) that works exactly on this subset, and fails for anything not strictly conforming to this.
Of course, this is not as satisfying as a "clean slate" approach, but on the other hand, this is a clear migration path with backwards compatibility - which is always good to have during a transition period to avoid all those bootstrapping and chicken-egg issues.
I've found librsvg to be pretty good. It's used for exactly this purpose in Gnome. You stick a Cairo surface behind it and it translates the operations to that.
https://github.com/GNOME/librsvg
However, admittedly, I use it in combination with a full blown browser because it doesn't need/handle text completely. I like SVG, but I too have accepted that if I want stuff to render properly, the only place to find a usable and complete SVG engine is in a web browser.
https://github.com/GNOME/librsvg
However, admittedly, I use it in combination with a full blown browser because it doesn't need/handle text completely. I like SVG, but I too have accepted that if I want stuff to render properly, the only place to find a usable and complete SVG engine is in a web browser.
Maybe something like this: https://en.wikipedia.org/wiki/Haiku_Vector_Icon_Format
> Why is there no libsvg like libjpeg or libpng?
nanosvg is pretty good:
https://github.com/memononen/nanosvg
nanosvg is pretty good:
https://github.com/memononen/nanosvg
Here is a Go library for SVG generation:
https://github.com/ajstarks/svgo https://speakerdeck.com/ajstarks/svgo-code-plus-picture-exam...
https://github.com/ajstarks/svgo https://speakerdeck.com/ajstarks/svgo-code-plus-picture-exam...
> It does way too much!
And even so, it still has no hairline. All line widths are finite and change when zooming.
And even so, it still has no hairline. All line widths are finite and change when zooming.
It does, well, if following SVG 1.2 Tiny it does, at least. As far as I know it's implemented in Opera, FF, Chrome and Safari. Not sure about IE.
It's implemented as vector-effect: vector-effect="non-scaling-stroke"
There's an example here https://gist.github.com/lightjs/5372867
It's implemented as vector-effect: vector-effect="non-scaling-stroke"
There's an example here https://gist.github.com/lightjs/5372867
Only in IE/Edge. On other browsers you can prevent scaling of line-widths
> All line widths are finite and change when zooming.
That's good imho.
There is https://www.w3.org/TR/SVGTiny12/ which is a subset of SVG without scripting, without CSS styling. Not sure why it never gained more traction.
It still includes interactivity & scripting (https://www.w3.org/TR/SVGTiny12/script.html)! Even audio etc.! So that's probably why it didn't get traction.
Because SVG Tiny 1.2 still has support for scripting and CSS styling.
https://www.w3.org/TR/SVGTiny12/styling.html https://www.w3.org/TR/SVGTiny12/script.html
https://www.w3.org/TR/SVGTiny12/styling.html https://www.w3.org/TR/SVGTiny12/script.html
I trusted Wikipedia (which says otherwise) without checking the references. Argh!
It explicitly doesn't require that the engine do anything with the content of <script> tags, and CSS is explicitly unsupported - they simply use a small subset of properties from CSS as attributes.
But how to deal with things like line-wrapping, when fonts have unknown size? Somehow, it should be possible to programmatically determine how each line is broken up. A similar argument holds for hinting at low pixel sizes.
This means it is inevitable that SVG should be Turing-complete.
This means it is inevitable that SVG should be Turing-complete.
Image should be self-contained. Proper vector format should convert text into a set of vector primitives.
The files could get quite huge after that. Also one feature of svg (whether it is an advantage is for everyone to decide) is that it can render fonts as they are rendered in the other parts of OS. Which is why it can be seamlessly embedded.
also it does things weirdly and surprisingly - like right in the first codepen sample when she put width and height to be 100% of the viewport but the svg engine decided not to stretch it... ugh.
and that ignoring browser specific issues, for example svg and css filtering don't work on edge/ie11
but nice hacks I guess. the real takeaway are probably svg animations, those can make cool stuff without the keyframe weirdness.
and that ignoring browser specific issues, for example svg and css filtering don't work on edge/ie11
but nice hacks I guess. the real takeaway are probably svg animations, those can make cool stuff without the keyframe weirdness.
It isn't perfect and it works inside of OpenFL but Haxe has a svg render in OpenFL that makes it much smaller in size to import and is more stream lined.
https://github.com/openfl/svg
https://github.com/openfl/svg
> Why have interaction as part of an image format?
What about as part of a text format? Would anyone find that useful?
What about as part of a text format? Would anyone find that useful?
There is also librsvg. It is heavily used with linux desktops.
It's always been a curiosity of mine why SVG didn't get more attention from browsers through the years to solve the performance issues. It's open source, cross platform, "dynamic" in a sense AKA no compiling needed, light weight, supports shapes and text, offers immediate responsiveness, etc. Why the lack of love while we pour ever increasing energy into mangling HTML and CSS and every six months a new JS framework/module/whatever to try to make it work?
The problem with SVG 1.1 is, that it doesn't support text wrapping. Text wrapping came with SVG 1.2 Tiny years later, but this standard had been ignored at that time. Then came HTML5.
SVG support is a lot better now but it used to be horrible. A few years ago I wrote a simple game in SVG and it would be broken in almost all mobile browsers at the time.
[deleted]
>>offers immediate responsiveness
does it? Any examples of responsive grid system on SVG? What would be interesting.
does it? Any examples of responsive grid system on SVG? What would be interesting.
I think GP was referring to the fact that you don't need to generate SVG assets at multiple sizes for size/picture clarity balance, as you do with popular raster formats.
But GP was asking : "Why the lack of love while we pour ever increasing energy into mangling HTML and CSS"
SVG can't be, shouldn't be and never will be the replacement for HTML/CSS/JS.
SVG can't be, shouldn't be and never will be the replacement for HTML/CSS/JS.
SVG is the replacement for HTML when you're doing something graphical in nature, styling it with css and animating with js. I've always felt that there was a huge potential in SVG for building UI.
But GP's point is the opposite, that HTML/CSS/JS is being used too often for tasks that could be much more simply solved by SVG. I can think of a couple just in my current project.
That's exactly my point. It's seems the task now with Web UI is adapting to screen sizes and capabilities to build complex layouts of components that IMHO HTML/CSS is fundamentally not suited for. The leap from using SVG just for simple elements that scale to entire UIs that scale and shift their layouts doesn't seem to far fetched to me...Oracle, Google, Adobe, Microsoft all use(d) XML with a schema for their layout engines and yet the Web won't (cant?) While it has in its grasp an XML as well?
Cool, could you please explain what are they? To me, personally, SVG is the last resort.
In brief, our product includes a web-based process flow component, typical nodes-and-edges kind of thing. Much better done with SVG IMHO, with first-class support for box & line modelling and styling. But the powers-that-be decreed we'd do it all in HTML & CSS.
nodes-and-edges thing is the classic problem that is perfectly solved by SVG. Other than that it's quite useless though IMHO.
Well, I'll happily agree that SVG is a perfect fit for data-driven graphics, but that represents are reasonably large set of solutions, so I'd not say "useless" at all.
SVG works so fantastically well with React -- it's just part of the DOM, after all. Unless there are performance concerns, that reason alone would make me choose it over Canvas every time.
Shameless plug, one of my first experiments with SVG+react (+cljs): https://polymeris.github.io/carlos/ Done in one day, without knowing the tech.
Shameless plug, one of my first experiments with SVG+react (+cljs): https://polymeris.github.io/carlos/ Done in one day, without knowing the tech.
When I started learning React, I realised a dream of mine could finally come true: a proper Celtic Knotwork generator. Uses SVG and React together in harmony.
http://celtic-knotwork.online
http://celtic-knotwork.online
Pardon my ignorance, but aren't these patterns just composed of certain tiles in rows and columns? This is something you can do equally well with raster graphics, so what's the gain of using SVG here?
Scalable vector output?
I tried that on an earlier version, but there's complications ;)
The "double corded" style paints one side of a cord red and the other blue. The problem comes when the pattern changes what side is which. You can play around with it to see - put in some breakpoints and you'll see the "sides" switch on some cells. This can't be done with tiles.
The tile manipulation is actually no simpler than drawing SVG, because the hard bit is calculating the entry and exit points for each tertiary cell. And SVG produces better results :)
I also plan on doing some more stuff with it someday - like deforming the grid by moving the corners. This is pretty simple with SVG but would be really hard with tiles.
The "double corded" style paints one side of a cord red and the other blue. The problem comes when the pattern changes what side is which. You can play around with it to see - put in some breakpoints and you'll see the "sides" switch on some cells. This can't be done with tiles.
The tile manipulation is actually no simpler than drawing SVG, because the hard bit is calculating the entry and exit points for each tertiary cell. And SVG produces better results :)
I also plan on doing some more stuff with it someday - like deforming the grid by moving the corners. This is pretty simple with SVG but would be really hard with tiles.
Awesome. Is the code for this open source? (I'm just afraid the world could lose this should you decide to take it down some day!)
Not yet - it's on github (the site runs off Github pages) but I need to prune the repo of private keys before I open-source it.
Given the reaction here, I'll try and open it over the weekend :)
That's delightful, thank you for posting it!
Agreed. Going with SVG instead of something else to render the Jenkins pipeline graph has made our lives much easier when it comes time to make changes since we introduced it.
For anybody interested in some example code mixing React and SVG the PipelineGraph component is here: https://github.com/jenkinsci/blueocean-plugin/blob/master/je...
For anybody interested in some example code mixing React and SVG the PipelineGraph component is here: https://github.com/jenkinsci/blueocean-plugin/blob/master/je...
That's actually what got me into React as well - I was initially going to try my hands at a then-alpha of Angular 2, but it couldn't work with SVG. I then decided that React would be nice to try for a hobby project, and there we are: https://agripongit.vincenttunru.com/
Made this Chernoff ~Fish~ generator (http://meagher.co/chernoff-fish/) with React and SVG. They are a great pair!
We do exactly this (SVG + React) at Bleacher Report.
It’s basically the best of every world for us (visuals, code, etc) and we’re trying to convert as much as we can to this (takes a while... we have a LOT of logos for example)
It’s basically the best of every world for us (visuals, code, etc) and we’re trying to convert as much as we can to this (takes a while... we have a LOT of logos for example)
> Unless there are performance concerns, that reason alone would make me choose it over Canvas every time.
I agree, but ironically am one of the few here with a use-case that seems to be in the canvas-is-always-better category, and performance reasons aren't even the only motivation (although that matters too).
I'm working on a data browser of huge data sets, and the plotted data needs to maximise the use of the limited available pixels to convey as much information as possible (see [0] for an example). At that point canvas is the more convenient option.
[0] http://linnarssonlab.org/flamemaps/
I agree, but ironically am one of the few here with a use-case that seems to be in the canvas-is-always-better category, and performance reasons aren't even the only motivation (although that matters too).
I'm working on a data browser of huge data sets, and the plotted data needs to maximise the use of the limited available pixels to convey as much information as possible (see [0] for an example). At that point canvas is the more convenient option.
[0] http://linnarssonlab.org/flamemaps/
Very cool. You might need a seizure warning -
[core.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/c... and [svg.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/s...
Look clear enough for me to follow. Thank you.
Will work on this, too:
[core.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/c... and [svg.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/s...
Look clear enough for me to follow. Thank you.
Will work on this, too:
(:require [carlos.core :as core]))
I would say not fantastically - it is part of the DOM, but it is 1. XML - so namespaces? 2. SVG has it's own DOM - it builds on an extends the HTML DOM but React only understands the HTML DOM.
But I could also say these were minor quibbles.
But I could also say these were minor quibbles.
That's just not true, react does understand and is able to create svg elements in the svg namespace.
Most of that is a problem in browsers already as well. While SVG works without problems in other XML languages due to namespaces, browsers run it through an HTML parser and certain things are simply required by that parser for no good reason, e.g. that the XLink namespace prefix must be xlink and otherwise it won't work.
Agreed. Elm+SVG is also a dream.
Shameless plug:
ImageTracer is a simple raster image tracer and vectorizer that outputs SVG, 100% free, Public Domain.
Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:
https://github.com/jankovicsandras/imagetracerjs
https://github.com/jankovicsandras/imagetracerjava
https://github.com/jankovicsandras/imagetracerandroid
ImageTracer is a simple raster image tracer and vectorizer that outputs SVG, 100% free, Public Domain.
Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:
https://github.com/jankovicsandras/imagetracerjs
https://github.com/jankovicsandras/imagetracerjava
https://github.com/jankovicsandras/imagetracerandroid
Wow, this is cool. It looks like an API capable of things that Vector Magic[1] can do, but FOSS. Vector Magic has been excellent for some occasions where you have a rasterized clipart, but need it as a vector.
[1]https://vectormagic.com/
[1]https://vectormagic.com/
Inkscape does have such a feature too. While importing a bitmap image, you can specifically "convert" it to vector graphic. Works fairly well.
I love and use Inkscape exclusively for any SVG editing, but this particular feature in Inkscape is woefully under anything I've seen vector magic provides.
> Inkscape does have such a feature too.
Inkscape calls Potrace, but you can you use Potrace directly from the command line, too.
https://en.wikipedia.org/wiki/Potrace
Inkscape calls Potrace, but you can you use Potrace directly from the command line, too.
https://en.wikipedia.org/wiki/Potrace
It's nice that we've got the most valuable part of Flash: a vector rendering engine. I do miss Flash's editor for these types of content, though.
> I do miss Flash's editor for these types of content, though.
It's still here! It's now branded Animate CC[1], and (naturally) focuses on other output formats.
[1] http://www.adobe.com/products/animate.html
It's still here! It's now branded Animate CC[1], and (naturally) focuses on other output formats.
[1] http://www.adobe.com/products/animate.html
Right! But is it SVG or only Canvas?
Canvas, WebGL, or "a potentially limitless number of platforms with the new Custom Platform Support SDK" (https://helpx.adobe.com/animate/how-to/publish-multiple-plat...)
The product itself can export to SVG (https://helpx.adobe.com/animate/how-to/export-image-svg.html), but I get the impression that's only for individual frames.
Edit: https://blogs.adobe.com/creativecloud/export-svg-animations-... exports SVG animations, but only, it seems, for special types of documents ("From here you simply create a new “Snap.svg Animator” document type and begin creating content s you would normally. Publishing your content then generates a boilerplate HTML file along with all the assets you need, giving you an example of how to embed your animation into a webpage.")
The product itself can export to SVG (https://helpx.adobe.com/animate/how-to/export-image-svg.html), but I get the impression that's only for individual frames.
Edit: https://blogs.adobe.com/creativecloud/export-svg-animations-... exports SVG animations, but only, it seems, for special types of documents ("From here you simply create a new “Snap.svg Animator” document type and begin creating content s you would normally. Publishing your content then generates a boilerplate HTML file along with all the assets you need, giving you an example of how to embed your animation into a webpage.")
I just spent all day trying to manually wrangle SVG in the browser. I'd be happy with a good static SVG editor to be honest.
Inkscape is OK, but a little rough. Take a look at Affinity Designer. It is very polished and has a feature set approaching Adobe illustrator at a very reasonable price. It's also well supported by the publisher.
I've been using both recently. Affinity Designer has a much, much better interface but I keep finding features and options missing that make it frustrating for coding projects. You can't easily open an SVG file, edit it and quickly save to the same SVG file without going through several clicks and setting options to export ("save" will save in a proprietary format). There isn't a command line interface for exporting either. I can't see a way to edit the SVG XML either (you can do that in Inkscape) which is important when you're wanting to script it later.
For previous projects, I've had workflows where images were extracted from one place, added into existing SVG files and Inkscape was scripted to slice up and export sections into PNG files. I can't see a way to do anything similar with Affinity Designer.
For previous projects, I've had workflows where images were extracted from one place, added into existing SVG files and Inkscape was scripted to slice up and export sections into PNG files. I can't see a way to do anything similar with Affinity Designer.
Inkscape is what I always use for editing static SVGs. Not using it enough to become familiar with it myself, the interface is usually intuitive enough for me to guess my way to success.
My biggest gripe with inkscape is that it suffers from some sort of floating point precision error, when you do certain copy/paste/transformation operations it mercilessly outputs more digits of significance than are necessary, which bloats the text and peeves off someone who must obsessively keep their ml clean
And also the output png is sometimes unpredictable. I hate it when what's supposed to be flat-coloured in svg turns out to be this 'pixelated-swirl' in png. I also find minimising operations can reduce this effect.
Experienced Flash developers would rasterize complex vector shapes on the first load to consume less CPU by raw vector rendering, especially animations. So it's still not a Flash replacement.
That’s Canvas+SVG+JS then. Basically.
SVG has the opposite performance profile of Canvas.
SVG hits a performance ceiling as number of elements increases. Canvas, since it's rasterized image can handle a rasterized representation of millions of SVG elements.
However as Canvas dimension increase, it will hit a performance ceiling.
SVG hits a performance ceiling as number of elements increases. Canvas, since it's rasterized image can handle a rasterized representation of millions of SVG elements.
However as Canvas dimension increase, it will hit a performance ceiling.
In my experience, canvas 2D also has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.
For example, try drawing hundreds of coloured rectangles per frame. Easy, right? If you're using WebGL, or any sensible graphics API, yes. If you're using canvas, the web-browser will parse and re-parse your colour expression CSS n times per frame. Enjoy your 100% CPU usage.
For example, try drawing hundreds of coloured rectangles per frame. Easy, right? If you're using WebGL, or any sensible graphics API, yes. If you're using canvas, the web-browser will parse and re-parse your colour expression CSS n times per frame. Enjoy your 100% CPU usage.
[deleted]
> has a number-of-elements performance ceiling if you're drawing things rather than using images, which feels like it defeats the purpose.
Well you can generate your imagery programmatically and then render it to canvas as a raster image. Canvas is not purely for implementing a web based drawing app.
Well you can generate your imagery programmatically and then render it to canvas as a raster image. Canvas is not purely for implementing a web based drawing app.
But you can also embed a raster image in SVG.
The context of the discussion is to leverage SVG's DOM based approach to render on screen elements
Software rasterisation is slow and power-inefficient, and does not scale particularly well with screen size.
when you are faced with between rendering hundreds of thousands of SVG DOM element vs in memory generation of a final raster image, the latter will always be more performant.
That’s not exactly surprising - you’re describing a problem with basically every graphics engine.
Rasterizing expensive operations before drawing to screen is usually job one of a rendering pipeline
Rasterizing expensive operations before drawing to screen is usually job one of a rendering pipeline
Real graphics APIs can handle dynamic geometry efficiently, have a batching mechanism, and don't force you to express colours through CSS strings.
Rasterising ahead-of-time is all well and good, but it's not something you should have to employ just to draw simple polygons.
Rasterising ahead-of-time is all well and good, but it's not something you should have to employ just to draw simple polygons.
I wouldn't say the opposite, just ... different.
Basically, canvas performance depends a lot on how many pixels you draw and how you draw them (blitting an image vs. drawing a gradient are very different things, obviously).
SVG performance depends on how many things in the DOM are changed at the same time (and then it's mostly dependent on how well the browser can avoid redraws – that's an area where we frequently encounter bugs when either too much or too little is redrawn). A large static image¹ manipulated only via affine transforms performs quite well; an image containing lots of different things that all vary constantly is bad. But as long as the viewport isn't too large, canvas can be a viable alternative to SVG if the visualization is simple.
¹ Unless written like this one: https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...
Basically, canvas performance depends a lot on how many pixels you draw and how you draw them (blitting an image vs. drawing a gradient are very different things, obviously).
SVG performance depends on how many things in the DOM are changed at the same time (and then it's mostly dependent on how well the browser can avoid redraws – that's an area where we frequently encounter bugs when either too much or too little is redrawn). A large static image¹ manipulated only via affine transforms performs quite well; an image containing lots of different things that all vary constantly is bad. But as long as the viewport isn't too large, canvas can be a viable alternative to SVG if the visualization is simple.
¹ Unless written like this one: https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...
(Edit moved to here from the wrong thread)
This comes up on each SVG thread and I post the same comment each time (so excuse me if you've heard this from me before).
We render SVG that contain beyond 100k nodes in the browser and find that it works fine. You need to be careful with your manipulations and we've developed a couple of tricks to keep things snappy, but the final experience is great.
Here's a demo of it in action with a smaller SVG
https://www.countfire.com/product-demo/
This comes up on each SVG thread and I post the same comment each time (so excuse me if you've heard this from me before).
We render SVG that contain beyond 100k nodes in the browser and find that it works fine. You need to be careful with your manipulations and we've developed a couple of tricks to keep things snappy, but the final experience is great.
Here's a demo of it in action with a smaller SVG
https://www.countfire.com/product-demo/
so with your 100k node ceiling. Have you tested across different OSs/CPUs/Browsers? Have you found tremendous variety in performance?
There's not a specific ceiling. This morning I did a quick test with 400k nodes and we sometimes get 2-3 million or more.
We only use chrome because Firefox struggled in the initial testing. Having said that, I haven't tried in anything other than chrome in ages and I'd wager the situation has changed a lot in the last couple of years.
We only use chrome because Firefox struggled in the initial testing. Having said that, I haven't tried in anything other than chrome in ages and I'd wager the situation has changed a lot in the last couple of years.
Only use Chrome? Your product only supports Chrome?
That's one of the issue i have with SVG browser implementation varies so much. Our product that is performant in Chrome sucks in IE11
That's one of the issue i have with SVG browser implementation varies so much. Our product that is performant in Chrome sucks in IE11
Yeah, for the moment we only support chrome. I know it's not ideal, but it sure is nice not having to worry about cross browser issues :-)
What's the slow bit in IE? Is it the svgs?
What's the slow bit in IE? Is it the svgs?
that's not 100k unique elements though, it's 100k instances of a set of <100 unique elements using <use> isn't it ?
No, in our case they're all unique elements - unfortunately for me! That demo example is actually much smaller though (2k nodes).
Here's an example with over 150k nodes [1]. To be honest, we would normally doctor documents that had this many nodes to make the experience smoother for users. You'll notice that it's a bit sluggish when you zoom in and out, but panning is the same speed regardless of number of elements, and updating elements within the document is fast too.
[1] https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
Here's an example with over 150k nodes [1]. To be honest, we would normally doctor documents that had this many nodes to make the experience smoother for users. You'll notice that it's a bit sluggish when you zoom in and out, but panning is the same speed regardless of number of elements, and updating elements within the document is fast too.
[1] https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
performance degrades to <10fps above 2k nodes (2k random circles in an svg) for me regardless of browser
What are you doing with them? Animating them?
nothing - only changing the transform matrix on the root <g> for pan/zoom
Can you move it further up and are you using 3D?
do 3d css transforms make that much difference ?
You can use something like `transform:translateZ(0px)` to force a subsection of the dom to exist on its own rendering layer. Then you can transform the parent nodes and they'll move the lower layer around as if it were a static picture that they don't need to redraw. I'm not sure how well this works within an svg, but you can certainly use it to do your transformations outside the svg.
ok i dug out the project I was thinking of and I was wrong - performance is fine at 10k nodes. adding translateZ causes a slight delay after changing the transform matrix while it re-renders the bitmap, and you see the switch - thanks for the advice
Choice between SVG and Canvas comes down to a balance between performance and interactivity, IMO. It is very easy to attach events and create interactions with a SVG object -- much harder to do that in Canvas (basically, you have to keep track of everything that was drawn). The flipside is, Canvas it effectively a bitmap, doesn't care what the pixels are, so the complexity is a constant regardless of what is drawn. SVG renderers will start to bog down once there are "too many" elements.
coming soon, full SVG websites featuring:
- loading bar until website is fully loaded
- animated buttons that bounce and flash
- full screen 2 second transitions from page to page
- all in one page, no urls!
feels like 2010 again : ]
- loading bar until website is fully loaded
- animated buttons that bounce and flash
- full screen 2 second transitions from page to page
- all in one page, no urls!
feels like 2010 again : ]
While SVG can do a lot, there are certain things that it isn't optimized for. In particular animating lots of shapes simultaneously. The animation of the globe exploding into a bunch of triangles from the slides is a good (bad?) example of this. Also, there can also be inconsistencies is in the rendering of SVGs between browsers.
That’s not really SVG that’s being bad there - it’s that browsers haven’t optimized for it.
They will if more people use it.
SVG in Chrome can be particularly painful due to their mediocre support of some things (sometimes outright contradicting the spec).
That’s a vendor issue tho, nothing intrinsic to the format.
They will if more people use it.
SVG in Chrome can be particularly painful due to their mediocre support of some things (sometimes outright contradicting the spec).
That’s a vendor issue tho, nothing intrinsic to the format.
Ironically we found that IE had the best SVG performance for quite a while (by now the others have mostly caught up). And then they broke a lot of things behaviour-wise in Edge again for quite some time. Performance was still great, but if your image doesn't look like it should it doesn't help.
True, though I’ve often found you have to be doing some rather obscure or strange things to screw up basic display
Or advanced CSS.
Or advanced CSS.
I use svg all the time to make tiny web interfaces for embedded systems. When the entire web app has to fit in 350k, you don't have space for gif's or jpg's.
Had to do almost the same thing in 2013 with internet lightbulbs. I had to draw a page without buffering as even page's full html was bigger that MCU's ram
On the other hand: http://www.oreilly.com/gnn/gnnhome.html
HTML plus 11 images in just 26KB.
HTML plus 11 images in just 26KB.
If your embedded system only has 350 kB of space for your app how on earth do you fit a browser in there? Or do you only use the 'static' features of SVG?
Usually this is done in a 'Bring Your Own Device' scenario, where the user has a standard mobile/tablet that the UI is shown on.
Using a webapp served by the embedded device allows a zero-install workflow, and zero-config (assuming network connectivity is taken care of).
Ah I see. I was imagining something with its own display, like a meeting room screen.
The embedded system only contains the web _server_. The user has the browser on their desktop/mobile system.
That's very interesting. Would be cool to see a generalized example of the kinds of interfaces you're building.
The most impressive rabbit I've pulled out of the SVG hat in this regard is being given a 2.1MB logo and told that it had to appear full screen during the log in and be "crisp and not all jaggy".
Did it in about 900 bytes.
Did it in about 900 bytes.
With inkscape?
You got it. Imported the jpg and traced it with Inkscape. Hand optimized the SVG and inlined it right into the html of the login page.
Logos are typically shipped in SVG or Adobe Illustrator format aren't they? Even the old style ones had technical specifications. Seems odd you'd have to hand trace a JPEG.
Ha! Yeah. I think maybe you and I might travel in slightly different circles.
interesting use case for super small performant applications. Can you give us a screenshot it would be nice to see it in the wild.
SVG is good as long as it's not abused.
All the kb saving are meaningless with performance issues caused by lots of nodes, gradients, etc.
It's great for responsive icons, but for a full interactive UI with illustrations bitmaps are the better choice IMO unless you really need dynamic scaling.
Just because you can do it doesn't mean you should.
All the kb saving are meaningless with performance issues caused by lots of nodes, gradients, etc.
It's great for responsive icons, but for a full interactive UI with illustrations bitmaps are the better choice IMO unless you really need dynamic scaling.
Just because you can do it doesn't mean you should.
Beware of using it for responsive icons. Popular browsers render SVG icons orders of magnitude slower than fonts, with the same vector content and scalability.
I recently had to convert an entire UI from SVG icons to fonts + bitmaps because the performance had gone down the drain, with just a few dozen different icons.
I recently had to convert an entire UI from SVG icons to fonts + bitmaps because the performance had gone down the drain, with just a few dozen different icons.
It's awesome. last time, I using SVG to import image to pdf files (using TCPDF). The quality is clearly & beautiful. Now, Thank you for your introduction about another things SVG can do on the website.
Her talk on the topic at vueconf was pretty good too https://youtu.be/gJDyhmL9O_E
I've used SVG to design custom PCBs using traces as magnetic coils, something that, surprisingly, doesn't have a good industrial software package for. Everything in PCB design software is geared toward routing wires conveniently between components, but if you try to actually use the wires as actual components, it's almost impossible to freely design. And even regular PCB design software feels almost unchanged since the 1980s or 1990s. Incredibly clunky.
Here's a good Hackaday article on converting SVG to PCB file formats: http://hackaday.com/2016/01/28/beautiful-and-bizarre-boards/ PCBModE is one package I tried for a while: http://pcbmode.com/ Boldport uses this toolchain to make beautiful PCBs relying heavily on SVG: https://www.boldport.com/
I had a hard time with all these packages, however, and ended up just hacking it together by hand with python code and outputting in KiCAD format. I wasn't even able to get KiCAD to read/render it properly (too many weird elements), but since OSH Park (where I got my PCBs from) takes KiCAD format directly and gives you a preview, that all worked fine, and when I ordered my PCBs, they arrived in working condition just fine the first time.
https://oshpark.com/
So yeah, SVG can do a lot, including make funky PCBs.
Here's a good Hackaday article on converting SVG to PCB file formats: http://hackaday.com/2016/01/28/beautiful-and-bizarre-boards/ PCBModE is one package I tried for a while: http://pcbmode.com/ Boldport uses this toolchain to make beautiful PCBs relying heavily on SVG: https://www.boldport.com/
I had a hard time with all these packages, however, and ended up just hacking it together by hand with python code and outputting in KiCAD format. I wasn't even able to get KiCAD to read/render it properly (too many weird elements), but since OSH Park (where I got my PCBs from) takes KiCAD format directly and gives you a preview, that all worked fine, and when I ordered my PCBs, they arrived in working condition just fine the first time.
https://oshpark.com/
So yeah, SVG can do a lot, including make funky PCBs.
Altium can do that sort of thing fairly easily. We use it for boards with waveguide filters, couplers, etc. (usually the geometry is designed and simulated in a field solver first, and then imported in, but you can do it straight in the software if you want).
The easiest way is to design the coil as a part, but you can use traces and arcs and stuff like normal in that.
The easiest way is to design the coil as a part, but you can use traces and arcs and stuff like normal in that.
That works well if your coil component is small and is just acting as a microwave RF component or something, but in my case I had a pretty complicated coil design (although simple conceptually) that spanned the entire PCB and interwove with other coils and wasn't arranged in a simple rectilinear manner. My original plan was to design the whole thing in Solidworks, which I did (and it was pretty easy to do), but there was simply no easy way to convert that into an actual PCB for manufacture (there is a Circuitworks module, but it's designed only for importing circuits to design around in Solidworks, not the other direction). Sitting there and manually making arcs and such in the PCB design software was just a non-starter. There are no parametric modeling features to speak of, and it's actually way easier to do what I did.
I think I used OpenSCAD to export to SVG.
I think I used OpenSCAD to export to SVG.
It has been almost 12 years, and we still don't have working word wrap with svg
We have it specified by now at least with SVG 2, but browser vendors have made it clear that they don want to support it at all, presumably because SVG 1.1 works well enough as a vector image format and more complexity and features could just be added by scripting. It felt a lot like browser vendors don't care about SVG at all beyond the extent that it's implemented at the moment.
They also tend to break non-static SVG things all the time which further suggests that things like applications or animations built with SVG are definitely not a use case they cater for (or that those things are simply very rare on the top 500 sites they test).
They also tend to break non-static SVG things all the time which further suggests that things like applications or animations built with SVG are definitely not a use case they cater for (or that those things are simply very rare on the top 500 sites they test).
You can embed HTML within SVG via SVG's foreignObject, and use HTML/CSS text flow layout within embedded HTML. But it works only on rectangular shapes, and not on IE.
You can also just absolutely position an HTML element on top of the SVG.
I wonder if we should encourage print designers to switch to svg (that is, if they don't already... it's not a world I know much).
I have in mind all those concerts or various events' png/jpeg files that are dropped on the web here and there. If they were svg files, it would be made easier for search engines to index their content.
Even without that, svg totally rocks. About a decade ago, I played with SVGWeb and made a showcase carousel presenting screenshots of projets with automated reflection on them (like it was common back then, a reverse image on bottom of actual image with a gradient from transparency to white to make an effect like if the ground was a mirror). I just had to upload a plain screenshot and everything was automated, I was mind blown, and surprised we seemed to go the canvas way instead (not so much, in retrospect).
Nowadays, I often make my icons as svg react components. It makes it so much easier to change their color or saturation on hover, this is very cool. We probably still have a long way to go to exploit all of svg potential.
I have in mind all those concerts or various events' png/jpeg files that are dropped on the web here and there. If they were svg files, it would be made easier for search engines to index their content.
Even without that, svg totally rocks. About a decade ago, I played with SVGWeb and made a showcase carousel presenting screenshots of projets with automated reflection on them (like it was common back then, a reverse image on bottom of actual image with a gradient from transparency to white to make an effect like if the ground was a mirror). I just had to upload a plain screenshot and everything was automated, I was mind blown, and surprised we seemed to go the canvas way instead (not so much, in retrospect).
Nowadays, I often make my icons as svg react components. It makes it so much easier to change their color or saturation on hover, this is very cool. We probably still have a long way to go to exploit all of svg potential.
If they're designing in Illustrator as most are they're usually working with vectors and have to use export to create their PNG/JPEG; SVG is right there as an export option. In my experience there's heavy inertia in the world of print though.
The SVGO-GUI has not been updated since 2015. I added out-of-the-box SVG optimization to my Optimage [1]. Fun fact: Node.js binary can be just 3MB compressed. ImageOptim [2] handles SVGs as well if Node.js is installed.
The transparent JPEG-in-SVG files can also be made with nothing but ImageMagick and Bash [3].
[1] http://getoptimage.com
[2] https://imageoptim.com/mac
[3] https://github.com/vmdanilov/svgize
The transparent JPEG-in-SVG files can also be made with nothing but ImageMagick and Bash [3].
[1] http://getoptimage.com
[2] https://imageoptim.com/mac
[3] https://github.com/vmdanilov/svgize
I'm trying to rewrite the good plugins of svgo into https://github.com/caub/svgz, something more flexible based on jsdom
Have not seen anyone mention it, but does it make sense to do Web Game development using SVG's with JavaScript? Has anyone tried this? Is it as fun as these slides make it seem or are there downsides to that approach?
I think you'd want to combine it with canvas to replicate Flash's cacheAsBitmap. As others have mentioned here though the decisions on where to use it (raster vs vector) and where not to use it need to be made carefully as your map of bits uses memory [(width x height x 3 or 4 for RGB/RGBA) bytes - soon adds up but maybe browser renderers optimise this somehow] in exchange for what you save on drawing calculations.
cacheAsBitmap brought a major performance boost to Flash when used wisely though. Maybe some libraries can handle this for you nowadays?
cacheAsBitmap brought a major performance boost to Flash when used wisely though. Maybe some libraries can handle this for you nowadays?
Isn't that basically Flash? It seemed like a popular way to do web games.
By "SVG can do that?", it appears they actually just meant "JavaScript can do that?", as all the cool animations and stuff are all just JS-driven.
Unless I misread it?
Unless I misread it?
This. Had a lengthy discussion exactly on this point in context of this very article couple of days back in office :)
Totally agree with you!
Totally agree with you!
Driven by JS and rendered using SVG.
If only there were a widely installed runtime where SVG and JavaScript could be used together
We attempted to do a complex animation in SVG and the primary complaint was that it killed the browser in terms of CPU and memory usage. Are we doing something wrong?
I had the same experience using SVG to render music notation. We hit a performance issue - high CPU usage, skips/stutters - with several hundred to a thousand nodes, some animated. Switching to canvas increased that limit, in that we were able to keep smooth rendering with larger documents.
Did you render a whole document as one SVG, or do tricks like one SVG per line or sheet?
The whole score was rendered as one SVG element, until we hit the performance limit. Now we're rendering each row of measures (a stack of staves) as a canvas element, and it performs much better for our purposes.
lots of svg elements animated in conjunction will surely have a negative performance impact. At work we created a mind mapping tool, in where every node has events (drag, click, raggin, dragend, contextmenu, etc). After 200+ nodes the performance hit was very high. We had to stop redrawing the whole graph after every interaction. What a bummer.
I pray for screen readers.
SVGs are actually quite accessible to assistive technology. Here are some tips I used for a recent demonstration: https://www.sitepoint.com/tips-accessible-svg/
What image format do you recommend that would work better on a screen reader?
The article is proposing SVG for rendering responsive text for articles. So the screen reader comment is valid.
The text is all there, isn't? The first demo I liked at used svg to rearrange the page, but all the text would render like normal. Probably even works with a text only browser.
It is not, <text> is picked up by screen-readers without any issue.
In what order?
Have you ever looked at a text dump of a PDF?
Assuming it's a text-PDF in the first place, there's no guarantee that it's in any sensible order.
Of course, most Web writing is pastiche anyway.
Have you ever looked at a text dump of a PDF?
Assuming it's a text-PDF in the first place, there's no guarantee that it's in any sensible order.
Of course, most Web writing is pastiche anyway.
Maybe people are overusing images and part of the way they mentally justify it is vector graphics?
This talk was one of the highlights of Develop Denver 2017 for me. Glad to see it getting some more traction.
Thanks for the conference name. Were the talks videoed? If so, did they say when they'll be uploaded?
Very cool. SVGs can be very sensible choice for certain applications that canvas doesn't cover well.
Ok great now that we know SVG is awesome, where do we begin learning how to use it like a pro?
She also wrote a book: http://shop.oreilly.com/product/0636920045335.do
This is a very inspirational presentation. I'm blown away. SVG can be the solution our next wave of interaction now that Flash has almost completely died.
So, how crazy to use SVG for a cross-platform UI?
I did that. It works ok.
Some gotchas:
1. SVG has all these seemingly useful features that have non-obvious gotchas. Example: you can give rendering hints for svg or any child shape nodes, like "crispEdges" so that straight lines are aligned to the pixel grid (plus it might turn off anti-aliasing, but that's another matter). Great-- I've got boxes with 1-pixel borders that should always be pixel aligned to look sharp, so I choose that.
Then I notice that when I drag one of my "crispEdges" boxes to the right with the mouse, I get this weird flickering due to the "crisping" algorithm aliasing the sides of the box to the pixel grid in a way that changes the width of the visible box. (I.e., if I move the box 1 pixel to the right, the left side might align to the grid that is greater than xpos, while the right side might choose the grid that is floor(xpos).) As a result it looks like the box is "crawling" across the screen, or up the screen if you drag it vertically.
So I went back to manually aligning those boxes to the pixel grid to guarantee consistent box size.
2. The "paint server" concept is an over-engineered mess. It's incompatible with CSS gradient spec which makes it a pain to figure out how to make CSS and future of SVG play well. Sane frameworks like Snap.svg abstract away that and anything else you'd likely find inside <defs> tags. (Also, someone here on HN mentioned that <defs> junk depends on the id to reference content, which easily creates nameclashes if you use multiple inline svgs.)
3. There's some churn in the DOM interface for SVG-related utils. For example, at some point I wanted to get access to normalized path instructions for a given SVG path. But Chrome recently deprecated the old way of doing that and is in the midst of replacing it with a new geometry interface.
4. The syntax for specifying an arc inside an SVG path is weird. Like, so weird that code in an SVG library I read obviously just went straight through the instructions listed in F.6.4/F.6.5 of the SVG spec (using the exact same variable names) to simply hand off the values to Cairo, and the library still had a bug somewhere. That one isn't really a big deal-- I'm just fascinated by how the spec writers favored endpoint parameterization consistency over the user's ability to draw a pie chart without having to ask questions on StackOverflow.
5. The complexity of the spec and its interaction with the other HTML5 specs is obviously a pain point for browser devs. Sometimes I use devTools to make a quick-and-dirty realtime codepen inside about:blank which just parses a contentEditable div and injects it as innerHTML of an SVG. It's nice because you can prototype things with patterns and gradients quite easily this way. Except you can't reference gradients/patterns/etc. in Firefox this way because of god-knows-what-conflict between about:blank's baseURL and SVG's funcIRI. (Although you can base64-encode the data and inject it as the src of an img under Firefox.)
You see things like that all over. For example, the burgeoning web animations API looks really nice and works with SVG. But it works on CSS properties and not SVG attributes.
Some gotchas:
1. SVG has all these seemingly useful features that have non-obvious gotchas. Example: you can give rendering hints for svg or any child shape nodes, like "crispEdges" so that straight lines are aligned to the pixel grid (plus it might turn off anti-aliasing, but that's another matter). Great-- I've got boxes with 1-pixel borders that should always be pixel aligned to look sharp, so I choose that.
Then I notice that when I drag one of my "crispEdges" boxes to the right with the mouse, I get this weird flickering due to the "crisping" algorithm aliasing the sides of the box to the pixel grid in a way that changes the width of the visible box. (I.e., if I move the box 1 pixel to the right, the left side might align to the grid that is greater than xpos, while the right side might choose the grid that is floor(xpos).) As a result it looks like the box is "crawling" across the screen, or up the screen if you drag it vertically.
So I went back to manually aligning those boxes to the pixel grid to guarantee consistent box size.
2. The "paint server" concept is an over-engineered mess. It's incompatible with CSS gradient spec which makes it a pain to figure out how to make CSS and future of SVG play well. Sane frameworks like Snap.svg abstract away that and anything else you'd likely find inside <defs> tags. (Also, someone here on HN mentioned that <defs> junk depends on the id to reference content, which easily creates nameclashes if you use multiple inline svgs.)
3. There's some churn in the DOM interface for SVG-related utils. For example, at some point I wanted to get access to normalized path instructions for a given SVG path. But Chrome recently deprecated the old way of doing that and is in the midst of replacing it with a new geometry interface.
4. The syntax for specifying an arc inside an SVG path is weird. Like, so weird that code in an SVG library I read obviously just went straight through the instructions listed in F.6.4/F.6.5 of the SVG spec (using the exact same variable names) to simply hand off the values to Cairo, and the library still had a bug somewhere. That one isn't really a big deal-- I'm just fascinated by how the spec writers favored endpoint parameterization consistency over the user's ability to draw a pie chart without having to ask questions on StackOverflow.
5. The complexity of the spec and its interaction with the other HTML5 specs is obviously a pain point for browser devs. Sometimes I use devTools to make a quick-and-dirty realtime codepen inside about:blank which just parses a contentEditable div and injects it as innerHTML of an SVG. It's nice because you can prototype things with patterns and gradients quite easily this way. Except you can't reference gradients/patterns/etc. in Firefox this way because of god-knows-what-conflict between about:blank's baseURL and SVG's funcIRI. (Although you can base64-encode the data and inject it as the src of an img under Firefox.)
You see things like that all over. For example, the burgeoning web animations API looks really nice and works with SVG. But it works on CSS properties and not SVG attributes.
Exist a SVG rendered that is not web browser? ie: truly independent? maybe portable?
Welp, time to learn SVG! So much more functionality than CSS. Gorgeous examples. I wonder if it's much slower to load though?
Wow, svg sits there and does mostly nothing on my phone. Just like Flash! Can't pinch to zoom to read the text that was too small, just like Flash! Half the supposedly neat interactive gewgaws like "turn this gear" didn't react to any presses or gestures at all. Just like Flash!
Are you clicking on the animated gif of the demo or did you follow the link to the demo?
In the OP's linked slideshow those are just videos playing and not interactive demos (except for the CodePen one)
Events can be attached to SVG elements just like any other element in the dom. Pinch to zoom / pan etc can all be implemented fine. Your complaints might hold true with certain demos, but they're not limitations of SVG
Cool, but they're still not really supported by Safari
Shame Flexbox can't be used with SVG
geekit(1)
Flash has the "advantage" that it's used almost exclusively for advertisments. Mostly pretentious people (artists, photographers etc) have websites made of flash. So, by turning off Flash, you block the bulk of annoying ads. And you lose little by disabling Flash.
Would the same be true for SVG ? Would it be used mostly for ads, too ? Or even, can you selectively block only the SVG used for advertisments ?
Would the same be true for SVG ? Would it be used mostly for ads, too ? Or even, can you selectively block only the SVG used for advertisments ?
Unfortunately, that seems to be one of the bigger hazards for SVG.
It really is an amazing graphical tool. David Dailey has been posting some amazing stuff on Ello: https://ello.co/ddailey
(Which also uses SVG for most of its icons and buttons.)
But ... the potential for advertising/marketing abuse (or just sheer bad design / misuse) is so high. Unless there's a way to quash it....
Sigh. This is why we can't have nice things.
It really is an amazing graphical tool. David Dailey has been posting some amazing stuff on Ello: https://ello.co/ddailey
(Which also uses SVG for most of its icons and buttons.)
But ... the potential for advertising/marketing abuse (or just sheer bad design / misuse) is so high. Unless there's a way to quash it....
Sigh. This is why we can't have nice things.
Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).
Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).
Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)
When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.
Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)