6 ms·

Scalable Vector Graphics (SVG) 2 Draft

64 points by Fletch137 14y ago

homer-simpson 14y ago
Still no support for multiple pages? Is it possible to vote for such feature? I'm really glad to see progress on SVG and hope this will finally make Mozilla to support SVG Tiny Fonts. This bug on their Bugzilla is 11 (!) years open: https://bugzilla.mozilla.org/show_bug.cgi?id=119490 https://bugzilla.mozilla.org/show_bug.cgi?id=119490
- pmelendez 14y ago
  I am curious, why do you need multi-page support in an image format file? I don't think it is intended to be a document file format.
  - homer-simpson 14y ago
    It's not "image format file" - it is Scalable Vector Graphics format, there was pageSet in SVG Print draft already. It would be useful because a graphics (text layout) may span several pages, like in PDF.
    - pmelendez 14y ago
      Well Wikipedia disagrees with you since it states that SVG is a "vector image format" (not that wikipedia could not be wrong anyway). I would consider printing to be another story though. It is possible to have a page size that spans to several pages when printing, but still it represents just one page. PDF is not the best analogy because it was designed to be a document format from the beginning.
      - homer-simpson 14y ago
        SVG is Scalable Vector Graphics. And http://wiki.inkscape.org/wiki/index.php/Multipage http://wiki.inkscape.org/wiki/index.php/Multipage
        pmelendez 14y ago
        It is arguably that graphics and image are equivalent for this matter, on the basic meaning both terms imply visual presentation and none of them state a requirement for multi page. Anyway, I will stop here because this thread is reaching the futile point.
    - j4_james 14y ago
      I'm not sure exactly what you had in mind, but there is a CSS proposal to support paging in general on any kind of content. For example if you had a very tall SVG image, you would constrain the height of the block that it was in, and set the overflow-style to paged-y. The browser would then provide some form of control for you to page vertically through the content in that block. This stuff is currently documented in the GCPM module, but I suspect it will move somewhere else eventually. http://www.w3.org/TR/css3-gcpm/ http://www.w3.org/TR/css3-gcpm/
- ancarda 14y ago
  >This bug on their Bugzilla is 11 (!) years open Wow. And that's not the first time I've seen Bugzilla reports open for years. Does nobody work on these features or something?
  - homer-simpson 14y ago
    Look for example here: https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c113 https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c113 Some guy offered that his company could implemented it. No one said yes.
seliopou 14y ago
It's nice to see that SVG is getting serious about custom filter effects[1], and with any luck, compositing[2]. [1]: http://www.w3.org/TR/2012/WD-filter-effects-20121025/#feCustomElement http://www.w3.org/TR/2012/WD-filter-effects-20121025/#feCust... [2]: http://www.w3.org/TR/2013/WD-SVG2-20130409/masking.html#SimpleAlphaBlending http://www.w3.org/TR/2013/WD-SVG2-20130409/masking.html#Simp...
- justinschuh 14y ago
  I don't foresee CSS shaders shipping in any browser. The proposal is fundamentally at odds with pretty much every browser's accelerated graphics stack, and forces falbacks to slower, power-hungry modes of operation. The filtered results are independent of hit testing, meaning a filtered element can visually appear in an entirely different location than the corresponding hit target. The security implications are downright frightening, including leakage of image data, history, and other state across origins.
Aardwolf 14y ago
It would be awesome if it supported audio, music, mouse coordinates, realtime keyboard input, and variables. And if it already does: then something must be wrong because I would have expected many awesome SVG games on Newgrounds if it worked well.
- scarmig 14y ago
  SVG really isn't well suited for games. I think it's an awesome and underutilized technology, don't get me wrong, but SVG has a place and it really isn't games. The furthest I've gone is a Go game in SVG, but that's a special case.
  - glhaynes 14y ago
    Why not? I'm pretty ignorant about SVG (and about writing 3D/vector games in general), so I don't immediately see a reason why SVG wouldn't be well-suited to games. Is it just because browsers aren't as performance-optimized for it as they are for <canvas> and WebGL? I suppose for a "modern" game you'd want to have all sorts of textures and shaders which maybe aren't part of SVG? Edit: Or perhaps it's because the other technologies "carve out" a piece of the page just for themselves whereas SVG doesn't and so browser reflow/layout code has to be invoked more often when SVG elements are being used?
    - Wilya 14y ago
      Generally speaking, SVG is more integrated to the DOM than canvas or WebGL. Every shape you draw is a DOM node, which means you can easily interact with it (mouseover events, ...), but also that it's rather "heavy". It doesn't scale for effects as well as canvas and WebGL, you can't really display more than a couple thousand nodes without risking major slowdown. It's nice for very interactive demos and lightweight visualizations, not for rendering-heavy things like games.
      - pmelendez 14y ago
        Your point is very valid but only on the realm of web games using browser's native support of svg. For instance, you would not have DOM-related problems if you use svg files in a native mobile game. The downside of using SVG in a game is that the render is slower in comparison with a rasterized image. However, all graphics formats have pros and consts, so it always depends on how are you going to use them.
duopixel 14y ago
I'm glad to see Erik Dahlström of Opera on the list of editors. He is really active in stackoverflow[1] often pointing out clarification on tough SVG questions. I'm sure he is aware of the difficulties us average web developers face when approaching SVG. [1]: http://stackoverflow.com/users/109374/erik-dahlstrom http://stackoverflow.com/users/109374/erik-dahlstrom
- ygra 14y ago
  It's not the first SVG spec to bear his name in the list of editors.
nxn 14y ago
I am not sure if I am more upset at this not providing any native means of word wrap, or IE not supporting foreignObject. Seriously, a large use case for using SVG on the web is data visualization -- where you will often find yourself displaying labels which need to wrap to a given size in order to display cleanly. Add to this the necessity to move other text around based on the height of other text elements and you're looking at a mess of ugly alignment code.
- windsurfer 14y ago
  It does have text-overflow processing: http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#TextOverflowProcessing http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#TextOve...
  - nxn 14y ago
    That only gives you the option of how you'd like to see it clipped (ex: ellipsis, an indication that the full text is not shown), it will not enable you to wrap the text onto another line. As per word wrap itself, the spec states it is not supported in the intro, and makes a few suggestions (two are essentially doing it manually, and one isn't an option if you'd like IE support): http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#Introduction http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#Introdu...
    - WiseWeasel 14y ago
      It'll be a while before we have to worry about IE supporting SVG 2 in any case.
      - nxn 14y ago
        My concern, in this particular case, is that foreignObject isn't exactly a new addition to this spec, it's been mentioned in SVG specs since at least 2001, and the IE team apparently made the deliberate decision of not implementing it. I'm not sure what their rationale is exactly, but it doesn't appear like they will be changing their minds about it anytime soon.
WiseWeasel 14y ago
Looks like the biggest change is a move towards CSS3-like styling across the board, including many new styling options previously excluded from SVG, as well as reworking how some things were done to be more consistent with HTML/CSS. For example, they've removed defined clip/mask elements, and you now define those in the CSS. Overall, I like the changes; seems like it won't be as much of a leap to figure out how to do things in SVG vs CSS, and we've got a bunch more styling options for various elements. Here's a link directly to the changlog: http://www.w3.org/TR/2013/WD-SVG2-20130409/changes.html http://www.w3.org/TR/2013/WD-SVG2-20130409/changes.html

64 points by Fletch137 14y ago

Still no support for multiple pages? Is it possible to vote for such feature? I'm really glad to see progress on SVG and hope this will finally make Mozilla to support SVG Tiny Fonts. This bug on their Bugzilla is 11 (!) years open: https://bugzilla.mozilla.org/show_bug.cgi?id=119490 https://bugzilla.mozilla.org/show_bug.cgi?id=119490

pmelendez 14y ago
I am curious, why do you need multi-page support in an image format file? I don't think it is intended to be a document file format.
- homer-simpson 14y ago
  It's not "image format file" - it is Scalable Vector Graphics format, there was pageSet in SVG Print draft already. It would be useful because a graphics (text layout) may span several pages, like in PDF.
  - pmelendez 14y ago
    Well Wikipedia disagrees with you since it states that SVG is a "vector image format" (not that wikipedia could not be wrong anyway). I would consider printing to be another story though. It is possible to have a page size that spans to several pages when printing, but still it represents just one page. PDF is not the best analogy because it was designed to be a document format from the beginning.
    - homer-simpson 14y ago
      SVG is Scalable Vector Graphics. And http://wiki.inkscape.org/wiki/index.php/Multipage http://wiki.inkscape.org/wiki/index.php/Multipage
      - pmelendez 14y ago
        It is arguably that graphics and image are equivalent for this matter, on the basic meaning both terms imply visual presentation and none of them state a requirement for multi page. Anyway, I will stop here because this thread is reaching the futile point.
  - j4_james 14y ago
    I'm not sure exactly what you had in mind, but there is a CSS proposal to support paging in general on any kind of content. For example if you had a very tall SVG image, you would constrain the height of the block that it was in, and set the overflow-style to paged-y. The browser would then provide some form of control for you to page vertically through the content in that block. This stuff is currently documented in the GCPM module, but I suspect it will move somewhere else eventually. http://www.w3.org/TR/css3-gcpm/ http://www.w3.org/TR/css3-gcpm/
ancarda 14y ago
>This bug on their Bugzilla is 11 (!) years open Wow. And that's not the first time I've seen Bugzilla reports open for years. Does nobody work on these features or something?
- homer-simpson 14y ago
  Look for example here: https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c113 https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c113 Some guy offered that his company could implemented it. No one said yes.

seliopou 14y ago

It's nice to see that SVG is getting serious about custom filter effects[1], and with any luck, compositing[2]. [1]: http://www.w3.org/TR/2012/WD-filter-effects-20121025/#feCustomElement http://www.w3.org/TR/2012/WD-filter-effects-20121025/#feCust... [2]: http://www.w3.org/TR/2013/WD-SVG2-20130409/masking.html#SimpleAlphaBlending http://www.w3.org/TR/2013/WD-SVG2-20130409/masking.html#Simp...

justinschuh 14y ago
I don't foresee CSS shaders shipping in any browser. The proposal is fundamentally at odds with pretty much every browser's accelerated graphics stack, and forces falbacks to slower, power-hungry modes of operation. The filtered results are independent of hit testing, meaning a filtered element can visually appear in an entirely different location than the corresponding hit target. The security implications are downright frightening, including leakage of image data, history, and other state across origins.

Aardwolf 14y ago

It would be awesome if it supported audio, music, mouse coordinates, realtime keyboard input, and variables. And if it already does: then something must be wrong because I would have expected many awesome SVG games on Newgrounds if it worked well.

scarmig 14y ago
SVG really isn't well suited for games. I think it's an awesome and underutilized technology, don't get me wrong, but SVG has a place and it really isn't games. The furthest I've gone is a Go game in SVG, but that's a special case.
- glhaynes 14y ago
  Why not? I'm pretty ignorant about SVG (and about writing 3D/vector games in general), so I don't immediately see a reason why SVG wouldn't be well-suited to games. Is it just because browsers aren't as performance-optimized for it as they are for <canvas> and WebGL? I suppose for a "modern" game you'd want to have all sorts of textures and shaders which maybe aren't part of SVG? Edit: Or perhaps it's because the other technologies "carve out" a piece of the page just for themselves whereas SVG doesn't and so browser reflow/layout code has to be invoked more often when SVG elements are being used?
  - Wilya 14y ago
    Generally speaking, SVG is more integrated to the DOM than canvas or WebGL. Every shape you draw is a DOM node, which means you can easily interact with it (mouseover events, ...), but also that it's rather "heavy". It doesn't scale for effects as well as canvas and WebGL, you can't really display more than a couple thousand nodes without risking major slowdown. It's nice for very interactive demos and lightweight visualizations, not for rendering-heavy things like games.
    - pmelendez 14y ago
      Your point is very valid but only on the realm of web games using browser's native support of svg. For instance, you would not have DOM-related problems if you use svg files in a native mobile game. The downside of using SVG in a game is that the render is slower in comparison with a rasterized image. However, all graphics formats have pros and consts, so it always depends on how are you going to use them.

duopixel 14y ago

I'm glad to see Erik Dahlström of Opera on the list of editors. He is really active in stackoverflow[1] often pointing out clarification on tough SVG questions. I'm sure he is aware of the difficulties us average web developers face when approaching SVG. [1]: http://stackoverflow.com/users/109374/erik-dahlstrom http://stackoverflow.com/users/109374/erik-dahlstrom

ygra 14y ago
It's not the first SVG spec to bear his name in the list of editors.

nxn 14y ago

I am not sure if I am more upset at this not providing any native means of word wrap, or IE not supporting foreignObject. Seriously, a large use case for using SVG on the web is data visualization -- where you will often find yourself displaying labels which need to wrap to a given size in order to display cleanly. Add to this the necessity to move other text around based on the height of other text elements and you're looking at a mess of ugly alignment code.

windsurfer 14y ago
It does have text-overflow processing: http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#TextOverflowProcessing http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#TextOve...
- nxn 14y ago
  That only gives you the option of how you'd like to see it clipped (ex: ellipsis, an indication that the full text is not shown), it will not enable you to wrap the text onto another line. As per word wrap itself, the spec states it is not supported in the intro, and makes a few suggestions (two are essentially doing it manually, and one isn't an option if you'd like IE support): http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#Introduction http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#Introdu...
  - WiseWeasel 14y ago
    It'll be a while before we have to worry about IE supporting SVG 2 in any case.
    - nxn 14y ago
      My concern, in this particular case, is that foreignObject isn't exactly a new addition to this spec, it's been mentioned in SVG specs since at least 2001, and the IE team apparently made the deliberate decision of not implementing it. I'm not sure what their rationale is exactly, but it doesn't appear like they will be changing their minds about it anytime soon.

WiseWeasel 14y ago

Looks like the biggest change is a move towards CSS3-like styling across the board, including many new styling options previously excluded from SVG, as well as reworking how some things were done to be more consistent with HTML/CSS. For example, they've removed defined clip/mask elements, and you now define those in the CSS. Overall, I like the changes; seems like it won't be as much of a leap to figure out how to do things in SVG vs CSS, and we've got a bunch more styling options for various elements. Here's a link directly to the changlog: http://www.w3.org/TR/2013/WD-SVG2-20130409/changes.html http://www.w3.org/TR/2013/WD-SVG2-20130409/changes.html