back to listing index

SVG 2 new features | Hacker News

[web search]
Original source (news.ycombinator.com)
Tags: html css svg svg2 web-standards
Clipped on: 2016-08-14

Image (Asset 1/2) alt= Hacker News new | threads | comments | show | ask | jobs | submit jaytaylor (2085) | logout
SVG 2 new features (github.com)
108 points by okket 10 hours ago | unvote | flag | hide | past | web | 45 comments | favorite




Image (Asset 2/2) alt=

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.


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 [2] http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing [3] http://www.w3.org/TR/SVG11/filters.html


While I agree that multiline text boxes would have been great, Text on a Path is also useful on occasion.

What it comes down to is that if you look at SVG as vector graphics for the web, it's quite complicated, but if you look at it as part of replacing Adobe Illustrator, it may not yet have enough features. Certainly, you can't represent a circle perfectly with a bezier curve.


I didn't realise that and googled some more: https://math.stackexchange.com/questions/449035/is-it-possib...

Apparently "four cubic Bezier curves and gives an approximation whose maximum error is 0.0196% of the radius"


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.

PostScript routines written by humans can be pretty easy to read; I will try to dig up some that I wrote a while back.

Machine-generated PostScript is challenging for me to read.

I wonder how efficiency of modern PostScript compares to SVG.


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.


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


They are recommended quite often for icons now (but I don't have numbers on SVG vs icon-fonts)


"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/ 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/ uses SVG in the logo, the account icon and the arrows.

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.


> The thing is, almost nobody is using SVGs on the Web.

Google maps switched to SVG for street layers like ten years ago.


Pretty much the great data viz graphs produced by D3.js are built on SVG - https://d3js.org/

My own intuition is that what is wanted here is a vector-graphics Abstract Machine instruction set in the RISC style, where an implementer only has to write and optimize code for a set of orthogonal primitives, and then everything else "falls out" of that.

Such a vector-drawing ISA wouldn't be at all human-readable, but it'd be an excellent object-code format for other vector formats to compile down to.


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


You are forgetting that you can't AFAIK embed custom fonts so using them exposes you to the different way OS handle font-weight, font-face and friends. Soon the only programs able to open SVG will be the browsers.

Many of your concerns are addressed by 2.0, go give it a look.

> On this way you avoid all the common XML pitfalls like xml entities blowing up your memory.

DTDs are gone, and with them, entity definitions. This particular attack is no longer possible in SVG 2.0.

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

The data strings—sure, their syntax could be more natural, yes. But it's certainly not difficult to parse a data string if you pay close attention to the spec. These specs aren't the kind of thing that random programmers should be implementing anyway, you'll want a proper SVG library to parse the SVG for you, and the SVG library will come with a test suite. This is no different than the way we parse JSON or HTML—we farm it out to libraries because it's easy to get it wrong.

But most text standards will produce a few broken implementations, SVG is no different. HTML parsers have disagreed since the beginning of time, there were recently some exploits for non-compliant URI parsers, and people have often forgotten the weird way you encode supplementary plane characters in JSON. Heck, if you look at "plain text" we can see a history of buggy programs, such as the NUL bytes that appeared in filenames for a buggy NFS server or the C0 AF directory traversal attack.

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

Multi-line text is a feature of SVG 2.0.

> I really don't see how adding new features makes any of this easier, when SVG 2.0 is basically a backwards-compatible superset.

2.0 is not a superset.

Again, you may want to take a look at the linked article at the top. Check out the section titled "Removed". It includes non-trivial chunks of functionality like the DTD, which vastly simplifies the parser. SVG fonts are also removed, which is a big chunk of complexity.

Yes, if you're writing your own SVG parser, it can be a bit daunting, just like writing your own HTML parser. But removing the DTD and fonts is a win in terms of reduced complexity, and moving more attributes to styles reduce the complexity of making animations from the user's perspective.

For me, SVG will continue to be an essential part of the web. Maybe you won't use it for "images" per se, at least not the way you embed JPEG and PNG files into your web pages, but you'll still be using it if you use D3 or the other cool drawing libraries for HTML. Canvas isn't always the right tool for the job. Or, put it this way. SVG isn't just an alternative to PNG, it's an alternative to <canvas>.


My general point is that SVG is an extremely complex format and that its complexity is preventing further adoption. Removing SVG fonts isn't going to change anything about that, as nobody but webkit bothered to implement it anyway.

> This particular attack is no longer possible in SVG 2.0.

You still need to configure your xml parser the correct way, this doesn't really change anything.

> But it's certainly not difficult to parse a data string if you pay close attention to the spec.

Or you just change the spec to follow the buggy behaviour when a few implementation have the same bug: https://lists.w3.org/Archives/Public/www-svg/2010Apr/0042.ht... which leads to new bugs https://bugs.launchpad.net/inkscape/+bug/1284409

I think the amount of issues you can find around svg paths with a bit of googling make a pretty good case that the format is overly complex.


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


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?

Correct, and sometimes that happens automatically.

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.


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.


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.

I think what's really missing is an open binary vector graphics format which is compact and easy to parse. Adobe Flash's shape format is the closest I can think of at the moment.

You mean that PNG, the reason why we still use GIFs? ;)

Few people actually use GIFs anymore. Most image host convert them to video.

Wow. I didn't know that.

This is pretty interesting where imgur has a http://imgur.com/r/gifs section but it's all mp4.


Citation? Why Do I see .gif in most animated images then. Or the lack of a video player thing when I click them.

Try right-clicking on the .gif and select "show controls", if it's there. This works for me most of the time. It doesn't work at all for real .gif files, but it's true that most ".gif" files are actually auto-play looping videos with no sound and hidden controls.

Imgur and Gfycat convert gifs to either WebM or MP4—making them videos.

Imgur also introduced gifv—a faux extension—to easily identify video-enhanced gifs.

Of course, the internet is still full of glorious 256-color, chunky-sized traditional gifs.


Some important browsers still don't have a good video image story, and most SMS/chat systems are even worse. We generate animated gifs for our 3D animated emoji and stickers.

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.


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


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.

I have a similar use case (http://www.countfire.com) and we've found svg to be really good. We often deal with documents with hundreds of thousands of Dom nodes. Admittedly we have limited ourselves to supporting google chrome so that might be the difference. Though we did also have to spend quite a bit of time optimizing the way svg manipulation is handled to make things performant.

Wondering how you feel about that? Was all the extra effort worth it in the end? Considering you only support a single browser anyway. Imagine a similar effort per browser. There's even a lot of variance between Chrome, latest FF, IE Edge, etc.

In my case I wasn't even manipulating the actual SVG nodes, just using transform CSS operations on them (transform and transfrom3d).


The final result is really nice. The user experience is smooth, and that's what matters most.

I'm not convinced that using canvas would have saved me that much effort. You just don't know what's going to bite you until you start building with these things.

One of the nice things with svg is that I can work with it everywhere. In the browser, on the backend, I can even manually manipulate it in my text editor.

Fortunately I've opted to constrain myself to chrome. If I had to support all the browsers that would have been the thing that ate up all the time (irrespective of whether it was canvas or svg).

Anyway. Sounds like you've also experienced the complexities enough to understand that once you push things a bit harder than usual you need to do extra work to make things play nice :)

At the end of the day, I'm happy with the result. Besides, for all the trouble it's nowhere near as complex as other bits of our system!


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" xlink:href="google.com">text</text>

Would this break the apps using xlink:href?


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.

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

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

CSS for HTML has the color currentColor which can satisfy that sort of a requirement.

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

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.

Where are you seeing this? Is this not what you're referring to https://svgwg.org/svg2-draft/linking.html#AElementHrefAttrib... ?



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: