undefined | Better HN

0 pointsepistasis15y ago0 comments

The problem with SVG was that it wasn't really designed as much as it was dreamed. And it was also dreamed up in the middle of the whole "all data must be shoe-horned into XML" collective nightmare, which makes it less than ideal as a scene graph.

It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.

0 comments

4 comments · 1 top-level

haberman15y ago· 3 in thread

Any specific criticisms of SVG's design (or references to such), besides being built on top of XML (which is unfortunate, I agree)?

Also, what's wrong with the mainstream SVG implementations, like in WebKit and Gecko?

epistasisOP15y ago

For many many years the web browser implementations have been buggy and incomplete, and it was always difficult for me to figure out what I could and couldn't use on which browsers and which operating systems. I don't have any specific complaints other than a myriad of tiny tiny headaches that I've left in the past. A lot of them revolved around text APIs and especially the DOM interfaces. I ran into far fewer bugs and inconsistencies when just using static XML.

From what I can tell the browser implementations are getting much better. It has been very odd that browsers have been shipping half-broken implementations for years, and the specification was released in 2003, a full eight years ago.

I think that the failure to implement SVG can largely be traced back to the extreme breadth and complexity of the specification. It's much easier to read through the specification for OpenGL or Postscript than it was to make it through the SVG specification, though I admit that a procedural API is almost necessarily simpler and easier than a stateful scene graph that includes a procedural API on top of it. Maybe SVG Tiny and Mobile mitigate the problem, but those came far too late to make a difference, and SVG 1.1 certainly wasn't deprecated in favor of a smaller and more implementable set of functionality.

In ay case, I'm not going to be guinea pig for SVG again. I may pick it up when others have proven that it has several interoperable implementation on separate OSs, but I still consider it one of the bigger time-sucks and poor architectural decisions I've made. /rant

haberman15y ago

Thanks for writing that up. I've gotten more interested in SVG ever since Protovis's successor d3 adopted an approach of writing SVG directly. d3's has some impressive demos built on top of SVG in an impressively small amount of code: http://mbostock.github.com/d3/

I do think it's unfortunate that lots of W3C standards like SVG were well-positioned to be very widely used, but ended up being so big, complicated, and not informed by actual implementations. I've ranted about this before: http://news.ycombinator.com/item?id=2521885

david92715y ago

You say it much more eloquently than I could but I wholeheartedly agree. I'm done getting bitten by SVG when Canvas, while more work, never bites.

j / k navigate · click thread line to collapse