
SVG 2 new features - okket
https://github.com/w3c/svgwg/wiki/SVG-2-new-features
======
dietrichepp
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
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
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
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.

~~~
legulere
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_ima...](https://commons.wikimedia.org/wiki/Help:SVG#Creating_SVG_images_for_Wikimedia_Commons)
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.

~~~
danielbeeke
"The thing is, almost nobody is using SVGs on the Web."

I disagree.

I regularly visit codrops and they show a lot of cases how you can use them. A
lot of the frontend web development is using them a lot.

[http://www.ns.nl/](http://www.ns.nl/) the dutch train company, for example
uses a mix of inline svg, background image svg and scr tags with svgs.

[https://www.spotify.com/nl/](https://www.spotify.com/nl/) uses SVG in the
logo, the account icon and the arrows.

[https://www.digitalocean.com/](https://www.digitalocean.com/) svg is best
practise for having vector images on your site.

The nice thing of SVG is the compatibility with css, for the web it is a nice
tool to use.

~~~
legulere
Of course there are counterexamples but most websites aren't using SVG. Out of
the Alexa top 20 only live.com is using svgs everywhere where they make sense
and only yahoo.com is using them in some parts of the website.

------
tambourine_man
Meta: I don't get HN's new dedup algorithm. I submitted the exact same link 5
days ago:

[https://news.ycombinator.com/item?id=12254324](https://news.ycombinator.com/item?id=12254324)

~~~
jffry
I _think_ I remember hearing that the dedup would allow resubmission of things
that didn't originally get much traction/upvotes/comments, so that might be at
play here?

~~~
nathancahill
Correct, and sometimes that happens automatically.

------
goodplay
Maybe it was wishful thinking on my part, but there was a time when I hoped
that svg would be to vector graphics what png is raster images. With svg
continuing to gain complexity, all that hope is gone.

At this rate, it'll become another html spec.

~~~
gulpahum
You're right. SVG2 requires full CSS support. CSS brings lots of complexity,
like calc(), CSS variables and so on. All that is needed, because web
developers use SVG2 inline in HTML documents. It is also becoming more common
to embed HTML in SVG. It's going to be one big tag soup. All that is better
for the web, but worse as a stable image format.

There are also plans to create SVG-in-OpenType fonts, which would embed SVG
inside web fonts. I have very mixed feelings about that. It is nice to have
fonts with multiple colors, gradients and animations. On the other hand, do I
want to have the same compatibility problems with fonts as I already have with
HTML/SVG? I'm almost hoping that SVG-in-OT fails and Microsoft's simpler
multi-color font format wins.

~~~
ygra
It saddens me a bit, actually. SVG had lots of features way before CSS and now
they're forced to adopt them to not confuse people who use HTML/CSS. CSS to my
knowledge never even tried adopting features in an SVG-compatible way.

------
iamleppert
I tried to use SVG on a recent project and did not have a good experience. The
project was converting PDF building plans to SVG and then I had to do some
transformation UI to align them to a map.

It worked, but the performance was terrible for non-trivial documents.
Anything over 10 MB started to get unstable and provide for a bad UX in the
browser. There's no way to get any kind of incremental rendering, you have
very little control over the rendering process in the browser once you've
handed it off to SVG (terrible API), and there are all kinds of security
restrictions that make lots of hacks necessary if you're loading SVG from some
place like S3 (due to same origin policy, but there are some additional hoops
to jump through unique to SVG as well). Especially bad was the inconsistency
across browsers and different implementations. When something goes wrong in
the SVG engine internals, you get cryptic error messages (no stack traces or
indication of where to even begin -- most of the time the location of the
error referenced in the SVG document is wrong as well, or just at the root
element). Opaque "out of memory" errors, or the browser tab just crashes. It
very much felt like dealing with a black box.

For non-trivial use cases, it makes it very hard to debug. The goal of using
SVG was to standardize to a neutral vector format that we could use anywhere,
client or server, and leverage a lot of the tools that can deal with SVG or
can convert to/from SVG without having to write our own drawing "engine".

In the end it wasn't worth all the hassle and we ended up implementing our own
drawing using canvas primitives. Too bad.

~~~
danjc
We ported our Console off Silverlight to HTML and use SVG to render a workflow
designer which dynamically overlays HTML overlays for most editing.

Our experience with SVG has been fantastic and we've found it very performant
even on large workflows that are 20x screen area.

I should note that we are using React too with shouldComponentUpdate
implemented to optimize DOM mutation.

Example at [https://flowgear.me/s/hZfxYnf](https://flowgear.me/s/hZfxYnf)

~~~
ygra
We have a graph editing and display component, which is primarily built on SVG
(canvas rendering available, too). Performance is rarely a problem.
Admittedly, we do remove elements that are not visible from the DOM, for very
large graphs those have to be tweaked a bit (same goes for WPF). Generally
usability suffers before performance does, and most techniques of improving
usability also improve performance.

------
paradite
I am worried about the href changes: _' href' as a replacement for
'xlink:href'_ and xlink:href is in the Deprecated list.

I have been implementing links within svg using xlink:href:

<text
xmlns:xlink="[http://www.w3.org/1999/xlink"](http://www.w3.org/1999/xlink")
xlink:href="google.com">text</text>

Would this break the apps using xlink:href?

~~~
Drdrdrq
Afaik you specify svg version in the image, so support probably depends on
that. In other words, you should be safe as long as you use older version.

------
dredmorbius
David Daley of Slippery Rock University is involved with SVG -- I know his
work mostly through his Ello posting, but you'll also find a pretty
significant CV here:

[http://srufaculty.sru.edu/david.dailey/](http://srufaculty.sru.edu/david.dailey/)

He tends to post various experiments which continuously blow my mind, though
also mentioned he preferred the 1.2 spec to 2.0:

[https://ello.co/ddailey](https://ello.co/ddailey)

(The fact that Ello supports display of SVG images helps.)

------
rfrey
What's a reasonable timeframe one can expect to see browser support?

------
jwatte
I'd be happy with "ability to color arrow heads based on the arrow line
color."

~~~
ygra
Like fill='context-stroke'? It's a fairly prominent example in the spec.

------
etatoby
Finally SVG has an over-engineered, bloated, complex machinery capable of
emulating a conical gradient (hi-fi metal knob effect.) We can now retire and
give up this life of crime.

PS: CorelDRAW had it in 1992 and didn't need a CSS parser to do it.

------
ommunist
No more direct href links from SVG document? This is unwelcome change.

~~~
rspeer
They're deprecating "a xlink:href" and adding "a href". Sounds good to me. I
never had any idea why it had to be "a xlink:href" except that this was
designed when someone thought XML namespaces were a good idea.

~~~
Mikhail_Edoshin
XML namespaces still are a good idea.

~~~
rspeer
What problem do they solve? (Problems that were created by XML in the first
place don't count.)

~~~
Mikhail_Edoshin
With XML namespaces independent development teams can freely design their own
structures and interfaces and then mix them in a very granular manner without
danger of name clash. This promotes design and reuse of specialized mini-
language with exact precise semantic. xlink:href is better than plain href
because plain href is an informal convention, while xlink:href is code reuse.

~~~
rspeer
You're spinning an XML fantasy.

XML is not good at describing structures or interfaces. It does not have
precise semantics. The semantics of XML are so vague that you can't even tell
whether whitespace is significant when parsing it.

XML describes marked-up text. And yet it's awkward enough that it's not even
used anymore for the most common case of marked-up text (HTML), which is why
SVG is evolving to be more like HTML now.

~~~
Mikhail_Edoshin
The semantic of a computer language (and a markup language in particular) is
what the code does with it. Sometimes the code uses whitespace and sometimes
it doesn't; XML doesn't enforce either way and leaves this up to the app. When
necessary you can explicitly mark your preference in different parts of the
tree with the 'xml:space' attribute. This attribute has precise and
unambiguous semantic. It is also another example of why namespaces are
important: it's a universal attribute that can be used with any XML document,
by the virtue of namespaces it will never conflict with anything, it has a
clear and small area of responsibility so any software vendor can easily
implement it, you don't need to invent your own conventions or whatever, just
reuse it.

By comparison, HTML has almost no semantic. You have no idea what the code
(which code, by the way?) is going to do with your 'article' tags or tell
exactly how 'nav' is different from 'menu'; this spins endless debate about
which tag to use. I remember how people argued that using 'dl' for figures
with captions was, you know, "semantic markup" :) This is not semantic markup.
Semantic markup would be things like <date:timestamp value="..." /> that a
browser would _render in my timezone_ or <chess:position
move="white">...</chess:position> to describe a position on a chessboard so
that a search engine could find _similar positions_ or _chess parties where
this position has occurred_. This is semantic markup and this could be
semantic Web. And to make this happen we need to be able to develop small and
clearly specified mini-languages with precise semantic (=computer
instructions) and then mix them in a single document and this is what
namespaces are for. This is the vision behind XML. It's very sad that few
people grok it; most prefer to badmouth things they don't understand.

A proper markup language should either be low-level and describe, for example,
physical layout and such, or should be extensible so I can describe the
document in my own terms! I do not write a bunch of divs and h1s, I write, for
example, docs for a function with <synopsis>, <parameters>, <examples>, maybe
<notes> and so on. And then I mechanically convert it into a low-level
language for rendering. HTML is neither: it's not low-level, it's very hard to
control even the visual appearance, and it's not extensible either. It's bad
in all aspects.

(Also, XML not only describes marked-up text, it's the only practical way to
work with such text. All modern publishing uses XML.)

~~~
rspeer
> All modern publishing uses XML.

Okay, just because you don't like HTML5 doesn't mean you get to deny that it
_exists_.

~~~
Mikhail_Edoshin
Is that all you can say? It does exist, but it isn't much better than it was
in v4. A few more canned tags; big deal. I wonder why the minor syntactic
differences were so important though. Is it that hard to close a tag? And why
no empty tags, they're certainly more concise? These are probably rhetorical
questions. Sure HTML is superb; you still have to specify the time of your
upcoming webinar as plain text so the users from other side of the world would
have to look up what the WTF timezone is, but I'm sure there's a tiny half-
megabyte JS library with a clever regex to fix this.

XML is the only sane format to deal with marked up texts written in natural
languages, and this is precisely because it is extensible, so you can describe
the structure in terms that make sense to the subject matter and still be able
to process it with standard tools. It's also a perfect format for parsing
results, because XML is essentially a frozen syntax tree. HTML is just a
single fixed language; it's widespread and popular but not because it's
technically superior (same as JS and CSS).

~~~
rspeer
You really want me to say more?

You seem to have missed the point of my reply. You said "all modern publishing
uses XML", and in doing so, you were overlooking the biggest counterexample to
XML, and the biggest thing in modern publishing, which is HTML 5.

HTML is a huge, huge example of modern publishing. It _tried_ XML, when HTML 4
came along with XHTML. XML was basically designed around making XHTML work.
And then HTML _stopped using XML_ in HTML5. It took a revolt of all the
implementers of HTML, but people got behind it because everyone could tell
that XML wasn't helping.

So now you've got a syntax that was designed for marked-up documents, that
people don't really want to use for marking up documents, and it's also trying
to convey data structures despite that this involves horrible patches like
"xml:space" that no other format needs.

You were also hinting at APIs for communicating things like time zones and
chess moves. Real APIs don't use marked-up natural language. I work in natural
language processing, and to a first approximation, computers don't understand
shit about natural language. When you need to communicate data, you use data
structures.

If you want to communicate extensible data structures with hints about their
semantics, you've got some choices, like protobufs and JSON-LD. Or you can
keep patching XML and trying to make it convey data structures despite that
data structures aren't made of marked-up strings, but then people won't use
your API.

XML is also an unwieldy format for parse results. It's not a frozen syntax
tree, it's a tree with tons of stuff bolted on to the side. The format that
represents a syntax tree is S-expressions.

