

Scalable Vector Graphics (SVG) 2 Draft - Fletch137
http://www.w3.org/TR/2013/WD-SVG2-20130409/

======
WiseWeasel
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>

------
nxn
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.

~~~
moqups
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.

~~~
nxn
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.

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

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

------
seliopou
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...](http://www.w3.org/TR/2012/WD-filter-
effects-20121025/#feCustomElement)

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

~~~
justinschuh
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.

------
homer-simpson
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>

~~~
pmelendez
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
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
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
SVG is Scalable Vector Graphics.

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

~~~
pmelendez
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.

------
Aardwolf
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
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
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
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
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.

