Scalable Vector Graphics (SVG) 2 Draft | Hacker News Reader

Scalable Vector Graphics (SVG) 2 Draft

w3.org

64 pointsFletch13732 comments

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

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.

At Moqups ( https://moqups.com ) we've been through a very painful process of trying to implement a word wrap component in SVG and after a few months decided to throw it out and use foreignObject. We decided that it's impossible to be able to cover the thousands of text handling scenarios for all the languages and scripts out there and the performance makes it very unfeasible beyond a few hundred words. With few exceptions related to measuring text across browsers/operating systems, this was a very good decision.

Sadly it's also the main reason for why we're not planning to support any version of IE moving forward although many users request it.

Slightly unrelated, but I'm also happy to see getStrokeBBox in there. It's been a total pain to manually compute the stroked bbox of each stencil so the layout engine can properly arrange each element in respect to its painted area.

I actually implemented a very primitive word wrap function specifically for wrapping text in SVGs about two weeks ago. I took the approach of keeping an single canvas object in memory (completely detached from the DOM, 1x1 pixel dimensions) and using its "measureText" method for calculating string lengths. This made the algorithm fairly simple, and if you set the font on the canvas context correctly, the results will actually be fairly accurate -- though you might have to take into account any scaling that you have applied on the SVG.

This approach did not cause any noticeable change in performance, at least not in my use case where there are at most around 100 nodes of text that needed word wrapping. I can't really compare it with other approaches since I saw no need to take multiple stabs at the problem when my first attempt proved to work well enough. I would guess that it might be faster than actually creating SVG text elements and then trying to get their widths since you're eliminating a lot of overhead in the pre-calculation phase. Also, as far as desktop browsers go, anything that has SVG also has canvas, so there were no worries there about browser compatibility issues.

EDIT: But yeah, I'm just mentioning this in case you find some use for it. Looking at your link I would say you're much better off just using foreignObject.

It does have text-overflow processing: http://www.w3.org/TR/2013/WD-SVG2-20130409/text.html#TextOve...

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#Introdu...

It'll be a while before we have to worry about IE supporting SVG 2 in any case.

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.

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

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

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/#feCust...

[2]: http://www.w3.org/TR/2013/WD-SVG2-20130409/masking.html#Simp...

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.

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

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.

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.

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/

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.

SVG is Scalable Vector Graphics.

And http://wiki.inkscape.org/wiki/index.php/Multipage

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.

>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?

Look for example here: https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c113

Some guy offered that his company could implemented it. No one said yes.

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.

While we're at it, why doesn't SVG support webcams, networking, and email? Any modern rendering system should at least support email. Maybe it does but I haven't seen any serious providers using it.

While we're on the subject, SVG should also support a third dimension. With 3D printing becoming a reality, I think this is a crucial feature to have.

It seems to be backsliding. 1.2 had raw socket support: http://www.w3.org/TR/2004/WD-SVG12-20040510/#rawsocket

This is a bit rude isn't it? I believe your point could be taken in a better way without a condescending comment.

I suspect it was meant to be sarcastic.

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.

"SVG really isn't well suited for games"

I would disagree... as a graphics file format it is very suitable for games, specially given its size. It is not intended to be a multimedia document format (I believe he is comparing SVG with SWF which is not valid since they have different design goals).

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?

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.

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.

Depends on the type of game, the field is very broad. For example, if I had the intention of creating an online card game, I think SVG via d3.js would actually be my very first choice.

Reply on news.ycombinator.com