6 ms·

I like this. It looks like this isn't some new, complicated iteration on SVG, but rather a big cleanup effort to make this more similar to existing HTML+CSS te

I like this. It looks like this isn't some new, complicated iteration on SVG, but rather a big cleanup effort to make this more similar to existing HTML+CSS techniques, removing cruft from the "XML everywhere" era of the web. DTDs and xml:base are gone. The ability to specify geometric properties (like circle radius) is a big step up, so we can these properties using CSS the same way we would do it if it were a div in HTML. Improvements in text handling are a long time coming and will be appreciated. Overall, I wouldn't be surprised if this makes implementation easier than SVG 1.1 rather than harder, improving the proliferation of vector graphics on the web. Of course, you can still limit your images to SVG tiny if you want to.

legulere 10y ago
I think it's ridiculous that SVG has a complexity comparable with HTML. With SVG you first have to parse the file into a DOM, because otherwise you can't really apply CSS (for which you of course also need a parser). On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. If you want to show animated SVGs you need a javascript implementation, because half the browsers don't understand the animate-elements. Being able to include javascript probably is the reason why most image hosters don't host SVGs. Javascript in SVG opens doors to all kind of evil things like cross site scripting. So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. Every program supporting SVG got this wrong at least once, and some like Inkscape still have a buggy parser. So you look up how to render this path and you see that you just have to render the border, but there are gazillions of options how to render borders you all have to support. So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text, but silly things like text whose baseline follows a path [1]. Because internationalisation is important SVG files of course can show different things depending on the locale [2]. So afterwards you just have to apply filters, which are basically half a pixel based image manipulation program [3]. I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset. To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them. [1] http://www.w3.org/TR/SVG11/text.html#TextOnAPath http://www.w3.org/TR/SVG11/text.html#TextOnAPath [2] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing [3] http://www.w3.org/TR/SVG11/filters.html http://www.w3.org/TR/SVG11/filters.html
- vbezhenar 10y ago
  The way I see it is SVG is a format for humans (that's why it got all those shapes and tricky formats) and its main use-case is browser (so CSS and JS support is not a problem, because it's already there). There should be another simpler vector format for machines, IMO.
  - gulpahum 10y ago
    What would be the purpose of such a simpler vector format? Several formats already exist for various use cases: PDF for printing, SVG for web graphics (simple content and icons), OpenType fonts for vector based text and SVG as an exchange format between vector graphics apps. The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.
    - vbezhenar 10y ago
      > What would be the purpose of such a simpler vector format? To allow simpler implementation for both consumer and creator software. To achieve better performance (lower size, faster parsing and drawing). > The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that. SVG has some problems as a graphics format, which are highlighted in this thread. I'm not sure about PDF, I never saw it used as a vector image format, so can't judge much about it.
      - userbinator 10y ago
        PDF's graphics are an optionally-compressed-binarily subset of PostScript, which manages to be both human-readable and relatively simple to parse.
    - legulere 10y ago
      The thing is, almost nobody is using SVGs on the Web. Usually wikipedia is cited as a website that uses them, when in reality they're rendering them to raster images. They actually have a nice site with the problems they're facing: https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_images_for_Wikimedia_Commons https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_ima... Other issues are that files might be bigger than pngs and have bad performance. PNG and JPEG files are also universally usable outside of browsers. Linux systems often use SVGs for icons, but that's basically where the support stops. If I want to include a SVG in a latex I have to convert it to postscript or pdf. If I want to include a SVG into a Word document I have to convert it into an emf (enhanced metafile). You can't use SVGs for cocoa, UIkit, WinForms or MFC applications out of the box. The reason probably is the complexity to support SVGs.

legulere 10y ago

I think it's ridiculous that SVG has a complexity comparable with HTML. With SVG you first have to parse the file into a DOM, because otherwise you can't really apply CSS (for which you of course also need a parser). On this way you avoid all the common XML pitfalls like xml entities blowing up your memory. If you want to show animated SVGs you need a javascript implementation, because half the browsers don't understand the animate-elements. Being able to include javascript probably is the reason why most image hosters don't host SVGs. Javascript in SVG opens doors to all kind of evil things like cross site scripting. So you walk down your SVG DOM and begin to parse path data strings. The syntax seems understandable after a short while so you think you can easily write a parser. But the parser you'll write will be wrong because the details of the syntax are totally arcane, whitespace can sometimes be dropped (e.g. A.5.5.5 10.5.5 is the same as A 0.5 0.5 0.5 1 0 0.5 0.5), commas are allowed at some places but only one at most. Every program supporting SVG got this wrong at least once, and some like Inkscape still have a buggy parser. So you look up how to render this path and you see that you just have to render the border, but there are gazillions of options how to render borders you all have to support. So the next element you want to render is a text element, which is a huge joke because it doesn't even support multi-line text, but silly things like text whose baseline follows a path [1]. Because internationalisation is important SVG files of course can show different things depending on the locale [2]. So afterwards you just have to apply filters, which are basically half a pixel based image manipulation program [3]. I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset. To proliferate vector graphics on the web we actually need a way simpler flat format. The only thing you actually really need is bezier paths and a way to fill them. [1] http://www.w3.org/TR/SVG11/text.html#TextOnAPath http://www.w3.org/TR/SVG11/text.html#TextOnAPath [2] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing [3] http://www.w3.org/TR/SVG11/filters.html http://www.w3.org/TR/SVG11/filters.html

vbezhenar 10y ago
The way I see it is SVG is a format for humans (that's why it got all those shapes and tricky formats) and its main use-case is browser (so CSS and JS support is not a problem, because it's already there). There should be another simpler vector format for machines, IMO.
- gulpahum 10y ago
  What would be the purpose of such a simpler vector format? Several formats already exist for various use cases: PDF for printing, SVG for web graphics (simple content and icons), OpenType fonts for vector based text and SVG as an exchange format between vector graphics apps. The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that.
  - vbezhenar 10y ago
    > What would be the purpose of such a simpler vector format? To allow simpler implementation for both consumer and creator software. To achieve better performance (lower size, faster parsing and drawing). > The only use case I can think of is for standalone vector graphics images, but PDF or SVG is often good enough for that. SVG has some problems as a graphics format, which are highlighted in this thread. I'm not sure about PDF, I never saw it used as a vector image format, so can't judge much about it.
    - userbinator 10y ago
      PDF's graphics are an optionally-compressed-binarily subset of PostScript, which manages to be both human-readable and relatively simple to parse.
  - legulere 10y ago
    The thing is, almost nobody is using SVGs on the Web. Usually wikipedia is cited as a website that uses them, when in reality they're rendering them to raster images. They actually have a nice site with the problems they're facing: https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_images_for_Wikimedia_Commons https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_ima... Other issues are that files might be bigger than pngs and have bad performance. PNG and JPEG files are also universally usable outside of browsers. Linux systems often use SVGs for icons, but that's basically where the support stops. If I want to include a SVG in a latex I have to convert it to postscript or pdf. If I want to include a SVG into a Word document I have to convert it into an emf (enhanced metafile). You can't use SVGs for cocoa, UIkit, WinForms or MFC applications out of the box. The reason probably is the complexity to support SVGs.