4 ms·

SVG was mostly created by Adobe to establish an in-browser vector graphic model, based on their extensive experience in PDF. Once Adobe bought Macromedia/Flash

SVG was mostly created by Adobe to establish an in-browser vector graphic model, based on their extensive experience in PDF. Once Adobe bought Macromedia/Flash around 2003 or so, they mostly lost interest in it for a while. SVG2 is/was an initiative to modernize it (and is to be finalized these days based on actual implemented features) but browser vendors have indicated they're only implementing a small set of conservative features [1] considering many vector effect features for UI are already part of CSS. When SVG2 is finalized, it will probably just consist of a description of those SVG 1.1 and 1.2 feature actually implemented in browsers. [1]: https://nikosandronikos.github.io/svg2-info/svg2-feature-support/ https://nikosandronikos.github.io/svg2-info/svg2-feature-sup...

jacobolus 8y ago
SVG 2 adds a big pile of stuff, some of which seems completely unnecessary to me, https://github.com/w3c/svgwg/wiki/SVG-2-new-features https://github.com/w3c/svgwg/wiki/SVG-2-new-features But it doesn’t fundamentally change the concept, which as I said is to be a 1990s-style XML-based document format with a bunch of (frankly inconsistent and arbitrary) graphical elements in it, based on a 1970s drawing model. YMMV. It’s great that it exists because browsers don’t give web authors any alternative method to match many of its capabilities. But it’s just as much of a confusing and frustrating mess as all the other web specs.
- tannhaeuser 8y ago
  You keep repeating the "70s/90s" rant, but what's your recommendation to web authors for vector graphic content such as diagrams, maps, content in education, etc. that doesn't become obsolete when your JavaScript lib is superseded by the next one?
  - jacobolus 8y ago
    They should absolutely use SVG for this. The browser doesn’t have any better way to do it. The performance will likely be good enough for whatever they are trying to do; CPUs are super fast these days, and can render many thousands of graphical elements at 60 frames per second even if you are forced to render everything in a cache ignorant and super-high-overhead roundabout fashion, and could conceivably do it all 20x more efficiently on bare metal on the CPU, or 1000x faster on a GPU. If performance turns out to be unusably slow, they’re basically screwed, because the alternative (writing some WebGL thing from scratch) is way way harder. There are a bunch of inherent graphical problems baked into SVG implementations (like compositing done in the wrong color space, lack of support for reasonable color spaces, inaccurate rendering of very fine features, phantom rendering of hairline gaps between immediately adjacent shapes, poor text layout, many components which are too inflexible to handle straight-forward goals, weird inconsistencies with other common tools, various bugs and cross-implementation incompatibilities, etc. etc.) but implementing a whole vector graphics pipeline from scratch to fix those would take years of work from a team of experts, something akin to implementing a video game rendering engine. Someone just trying to make diagrams should live within the constraints of SVG and try to be happy with what it is, maybe with occasional grumping on a web forum.

jacobolus 8y ago

SVG 2 adds a big pile of stuff, some of which seems completely unnecessary to me, https://github.com/w3c/svgwg/wiki/SVG-2-new-features https://github.com/w3c/svgwg/wiki/SVG-2-new-features But it doesn’t fundamentally change the concept, which as I said is to be a 1990s-style XML-based document format with a bunch of (frankly inconsistent and arbitrary) graphical elements in it, based on a 1970s drawing model. YMMV. It’s great that it exists because browsers don’t give web authors any alternative method to match many of its capabilities. But it’s just as much of a confusing and frustrating mess as all the other web specs.

tannhaeuser 8y ago
You keep repeating the "70s/90s" rant, but what's your recommendation to web authors for vector graphic content such as diagrams, maps, content in education, etc. that doesn't become obsolete when your JavaScript lib is superseded by the next one?
- jacobolus 8y ago
  They should absolutely use SVG for this. The browser doesn’t have any better way to do it. The performance will likely be good enough for whatever they are trying to do; CPUs are super fast these days, and can render many thousands of graphical elements at 60 frames per second even if you are forced to render everything in a cache ignorant and super-high-overhead roundabout fashion, and could conceivably do it all 20x more efficiently on bare metal on the CPU, or 1000x faster on a GPU. If performance turns out to be unusably slow, they’re basically screwed, because the alternative (writing some WebGL thing from scratch) is way way harder. There are a bunch of inherent graphical problems baked into SVG implementations (like compositing done in the wrong color space, lack of support for reasonable color spaces, inaccurate rendering of very fine features, phantom rendering of hairline gaps between immediately adjacent shapes, poor text layout, many components which are too inflexible to handle straight-forward goals, weird inconsistencies with other common tools, various bugs and cross-implementation incompatibilities, etc. etc.) but implementing a whole vector graphics pipeline from scratch to fix those would take years of work from a team of experts, something akin to implementing a video game rendering engine. Someone just trying to make diagrams should live within the constraints of SVG and try to be happy with what it is, maybe with occasional grumping on a web forum.