SVG is too complex/heavy for simple tasks and actually is not that good for complex tasks - more or less complex image requires special editing WYSIWYG application to create it.
Let's imagine that you need to render simple icon using CSS that should change color on :hover:
div.icon {
background: url(simple.svg) no-repeat;
background-size: 1em 1em;
}
div.icon:hover { ??? what to do here to change the color ??? }
Just to render this thing you will need: to download the file, parse SVG, build DOM tree and "play" that DOM tree on canvas. Each task is not trivial.
While ago I've proposed at w3c-styles simple and lightweight solution for vector images and shapes in CSS - so called path URLs:
> You can see we’ve landed on directly injecting the SVGs directly in our page markup. This allows us the flexibility to change the color of the icons with CSS using the fill: declaration on the fly.
I would argue that rendering simple paths is not really the goal of CSS (or implementing icons for that matter). We already have images, we already have fonts. If there is a third way to render simple vector paths then transitioning to something more powerful (when somebody decides that they want colour in their icons) will be just more painful.
>> more or less complex image requires special editing WYSIWYG application to create it
I agree, it's like having to deal with images all over again; which we all know was a severe problem for the industry.
>> ??? what to do here to change the color ???
You see, that's because you picked one of the ways to use SVG that doesn't work the way you say you want it to. You are ignoring the other ways to handle the situation without the problem you're claiming. I would say you are being borderline dishonest just to make your false point.
As for the path idea, I don't think I would necessarily be against such a thing. But it would seem unwieldy with a complicated path.
SVG is amazing, my main concern about it. it is because it creates a huge burden to browser developers. The spec is huge [1]. And some parts are outdated[2].
> SVG is amazing, my main concern about it. it is because it creates a huge burden to browser developers.
Yes, it would have been better if SVG was designed on top of something simpler; and this something simpler could be implemented by browser developers. Probably, such an approach is more secure too. But, I guess it is too late now.
- The first issue was the designer Im working with didnt know how to export to svg.
- Second problem is my svgs ended up with very weird numbers and groups. Such as the main groups offset was -60, 190 then another group to dlightly compensate. Then the paths themselves compensated further.
- Another issue is "cutouts" are nonintuitive for designers and also complex to reverse when they are curves.
- Another issue is linking and styling to an external svg. Despite you can put them in an image tag, it cannot be styled this way. If you put it inside a use tag, styling externally requires targeting ids.
- anothwr issue is that they dont follow the normal rules of width/height. By default they are 300x150 and takes a bit of patience to ensure they exist as 100% width (which I assumed was default)
Other than that, I am quite pleased with the format and am expecting great things for it!
Hand-written SVG, treated as elements of the markup (rather than an external black-box object or image), usually works well. It's easily* styled, scripted, and has good clean structure and values. There are, however, a couple of problems.
Hand-writing a complex graphic is difficult! (ex: editing coastlines on a map) Unfortunately, current WYSIWYG editors produce bloated, illogical output full of bizarre measurement schemes, unnecessary translations, and incompatible proprietary garbage - sort of like the bad old days of Frontpage and Dreamweaver.
*There are also some quirks in both styling and scripting them (as others have mentioned, height is one, another is having to use NS versions of DOM functions instead of normal ones - but only sometimes).
Maybe by the time SVG turns 21, those things will be mostly sorted out. It's still in its awkward teenage years.
Yeah, currently WYSIWYG tools generate pretty terrible SVG. Sketch is especially awful, Adobe almost as bad, Inkscape the least but still somewhat bad. SVGO helps sometimes with this, but it also sometimes chews up your document and spits out an empty SVG.
I see this in the wild all the time, though these days it's becoming less harmful as more developers learn to host their images (and all user uploaded files, really) on a separate CDN.
When I first heard about svg, I was excited. Finally everybody getting behind a vector graphics format... and since then the more I see the worse it looks. A boosted, text-oriented, JavaScript-enhanced resource monster. All the worst attributes of HTML, but in vector graphics.
Did anybody want this? I know I wanted a jpg of vector graphics - a resource-friendly small system for embedding vector graphics into things. Something where I don't have to worry about an image having an xss vulnerability. Something that degrades gracefully so it can still work in some form on an anemic piece of equipment.
But no. We throw bigger and heavier hardware at more trivial problems.
SVG is not a lightweight vector graphics format, which seems to be what you were hoping for. I agree that such a format would be useful as well.
However, for better or worse, web apps are a thing in 2016, and that means we need formats that lend themselves to programming and interaction. Having SVG do that for vector graphics is useful for much the same reasons as having HTML do that for text-based content and forms.
Text-oriented... what did you expect? Binary formats are tough to standardize. We have raster images, video, audio files, and fonts, but very few of those formats are "web" formats. Most of them are designed around getting the most bang for your bit to the extreme--an MPEG-4 decoder is a real beast, to be sure, and it's hardly a good model for vector graphics. Vector graphics follow more of a human authorship pipeline (capturing a series of drawing commands) rather than machine capture pipeline (sampling data at a certain frequency). JSON, XML, JavaScript, HTML, even HTTP are built on text-oriented protocols and formats because text-oriented systems are easier to standardize and extend. MPEG-4, MP3, JPEG, Vorbis, are binary protocols because they only exist to represent and compress narrowly-defined multidimensional data.
Resource-friendly for small systems--how would we reduce memory consumption? The alternative model for vector graphics is what, PDF or PostScript? They're not exactly models of restraint. SVG looks positively austere compared to PDF or PostScript.
The closest thing I can think of to your ideal "minimal binary" vector graphics is something like TTF, which is basically its own little nightmare compared with SVG. TTF has its own vulnerabilities, its own proprietary scripting system compiled to bytecode, et cetera.
For me, SVG is doing a great job of enabling really cool things like D3, and at the same time hammering more nails into the coffin that is Flash--something far more a resource hog than SVG. And we don't really need more 90s-era formats, we've got plenty of those, thank you very much. SVG is to images what HTML is to documents. You can build simple, static ones easily enough, and you can also make a little bit of magic happen if you throw in some JavaScript.
It looks like in the future we'll be embracing more binary systems. TLS, HTTP/2, and WebAssembly are some examples. But it took a long time to get the institutional expertise to invent such systems, and if we had rushed to use binary instead of text in the early days, we would have probably gotten it wrong in a bad way.
Besides... the hardware is getting bigger and faster anyway... we might as well deliver some good experiences with it. Most of your battery is probably going to power the backlight and GPS radio anyway.
It's like the W3C is reinventing Macromedia Flash, which was the choice for compact, interactive vector graphics around 10 years ago. I don't like what Adobe did to it after they bought Macromedia, but a subset of SWF would've fit the "resource-friendly small system for embedding vector graphics into things" use case very well. I wrote a substantial part of a SWF renderer --- in x86 Asm --- and it wasn't that difficult, because the format is actually quite simple to parse. An XML parser alone would've been larger than that, nevermind the SVG-specific processing on top of it.
On Windows, including historic, mobile and embedded versions, there are well-supported vector formats suitable for embedding images.
If your software paints stuff using GDI or GDI+, you can use windows metafile images, EMF/EMF+/EMZ.
If your software paints stuff using Silverlight or WPF or WinRT, the XAML format has descent support for vector graphics. On WinRT, it’s even compiled to binary form, BAML, to save resources in runtime.
SVG as a representation language for draw programs is pretty good. Most draw programs don't utilize it fully. While SVG can represent dimensions as inches or mm, most programs only support dimensions as pixels, which makes SVG useless for CAD drawings.
If you need drawings with lines and boxes, Inkscape is very helpful. Most drawings in Wikipedia are in SVG, and many were drawn with Inkscape. You can update drawings in Wikipedia by bringing them into Inkscape and editing them, then checking them back in as an update. It's not a read-only notation, like Postscript.
Manually tweaking SVG text, though? Painful. It's encapsulated like XML, so you can, but you probably shouldn't. After you've done that, most draw programs won't be able to handle the fancy stuff. And really, drawing by typing text is like pounding a screw with a hammer.
Timing! I just pulled a 4AM night last night creating my first ever Lua library, svglover[0], to facilitate SVG display in LÖVE[1], for a roguelike. Motivation was primitive[2] posted[3] last week. It's actually pretty easy to work with, even for lazy coders who find regex parsing acceptable like me[4] :) I'm no oldschool demo coder, but the coordinate transformation system is basically just a simple layer on top of an OpenGL pipeline. You don't even need viewbox, just groups with <g></g>
Gordon Lee[0] has made a ton of sophisticated SVGs for Wikipedia and its projects and recently presented at Wikimania. The Burj Khalifa[1] is one of my favorites. Inspired, I wrote this short script for fun that chops up a Blender file into PNGs[2] which I used to generate an animated SVG.
SVG works for the trivial graphics use cases that are presented. But it falls apart for anything that requires more complexity, or dealing with documents of arbitrary complexity.
There is little provision for incremental rendering, and poor control and visibility of the internals of the rendering process. Once you dump your SVG to the browser, that's basically it. There's no way to find out what is going on.
It's really nice to just set a break point in your imperative Canvas code, or WebGL code and see exactly what is happening, and use all the standard debugging and profiling techniques. I have yet to see the same for SVG.
We solved this issue by using a rendering engine that has rich tooling, strong profiling and inspection capabilities, and is centered around predictability - React.
D3 v4 provides all of its goodness in loosely coupled modules with clear boundaries, so you can use it for all heavy lifting that it's amazing at (layouts, animations, shapes), then setState() all over the place to reflect the results in the DOM. Performance wise, the only limits we are hitting are native SVG limits on the number of nodes.
Our visualisations are complex (science and finance, to an expert and expertly distracted audience), but no more complex than the rest of the app. React paradigm is predictable, well known, and has a deep user base to lean on. Performance and inspection tools are solid. And the only difference is that the render method has a <g> instead of a <div>.
Three years ago I was amazed by the versatility of SVG when I discovered it through D3 and it inspired our graphical designer to ask us designs never before seen in SaaS applications. Once you're willing to dive into the specifications, you'll find a treasure trove of possibilities.
There are some caveats beginning users should be aware of. First of all, better forget multi line text or sophisticated text layout within the SVG. I still think that's really missing in the current specification. As a commute project I once wrote the dynamic programming layout of Knuth (used in TeX) for SVG and JavaScript, but it was slow and didn't allow for multi line selections.
Another problem is rendering speed. SVG renderers can be fast, but you have to know what can be optimized by the gpu and what requires the CPU.
Pixel imperfections is a long-running problem with vector rendering engines. You can name "SVG" as a culprit, but any other format would suffer from the same problems because it is an implementation problem rather than a specification problem. The straightforward approach is "here's a buffer, let's think of the vector image as a series of drawing commands in that buffer", but that approach usually converts coverage to alpha at each step.
There are some interesting thoughts from nVidia on throwing GPU hardware at the problem. The specialized hardware on a GPU can handle coverage in a much more coherent way without paying a premium in processing and memory.
I'm wondering if it would be possible to parameterize SVG files. Suppose I have an icon in the file "icon.svg", it would be awesome if I could say in the CSS:
You can achieve something like that by setting the color of the containing element and then referring to currentColor within the styles for the SVG. If you use :hover and friends to change the color of the containing element, this does mean you can have the SVG change things like text or fill colours accordingly.
This technique is quite limited, though, as unfortunately it only allows passing of a single colour as a “parameter” to the SVG. In some cases, currentColor is redundant, as often if you just draw something in the SVG without specifying any colour explicitly, it will inherit the colour by default anyway.
Beyond that, you’re probably into scripting the SVG and all the vaguely-documented, non-portable, security-nightmarish possibilities that offers. For example, suppose you embed an SVG in your HTML like this:
In theory, this should log "green" to your console, assuming you load both the HTML and SVG from compatible origins. This is because window.frameElement should refer to the <object> element and thus should allow access to its attributes, containing HTML document, and so on. (Note that this only works with embedding; using <img> to load the SVG should block the scripting.)
In practice, having just tried it in Chrome, Firefox and IE11, and loading from both a local disk and over HTTP, Firefox works in both cases, Chrome works over HTTP but blocks locally, and IE11 blocks in both cases (with window.frameElement being set to null in the blocked cases here). So sadly although this might be quite a useful technique if you can control your environment, it’s definitely not portable to all major browsers.
I really like SVG and this was a great article that contained many things I didn't know.
That said, I _tried_ to use SVG for something as simple as displaying some multiline monospaced text with whitespace preserved, and found it's either really hard, or actually not possible (unless you position each glyph manually). Is that really the case?
SVG has another interesting application: it can be used as a UI language for graphically rich and complex interfaces, almost game-like but not quite. You often see this kind of interfaces in audio, i.e. soft synths/effects. Though you will need to create your own extension to the markup and a subsystem that supports it in your OS, which in the end is not too complicated.
As a designer using SVGs across the web, there are a few drawbacks that are easy to fix:
- platforms like Twitter and Google Slides not accepting SVGs. I assume this is due to security concerns.
- Using SVGs on a website doesn't render with included WebFonts like normal text would. This leads to outlining text, which is a huge maintainability burden.
- Graphics programs have tones of SVG bugs. Even "leading" software like Illustrator and Sketch have a lot of bumps in the road.
Overall really excited about SVGs and use them as much as possible.
Generally I agree that SVG is awesome, but there are a variety of cross-platform issues with it and I worry it does not get enough serious use to see them addressed. The status quo is pretty good, but if you run into issues there is not always a work around.
[+] [-] c-smile|9 years ago|reply
Let's imagine that you need to render simple icon using CSS that should change color on :hover:
Just to render this thing you will need: to download the file, parse SVG, build DOM tree and "play" that DOM tree on canvas. Each task is not trivial.While ago I've proposed at w3c-styles simple and lightweight solution for vector images and shapes in CSS - so called path URLs:
The path uses the same format as "d" attribute in SVG's <path> element: Parsing is trivial and rendering of such "images" is just a set of primitive drawing operations. No DOM or anything like that.More on the subject (with illustrations in Sciter) : http://sciter.com/lightweight-inline-vector-images-in-sciter...
[+] [-] ZeroGravitas|9 years ago|reply
I believe this is what Github recently started doing:
https://github.com/blog/2112-delivering-octicons-with-svg
> You can see we’ve landed on directly injecting the SVGs directly in our page markup. This allows us the flexibility to change the color of the icons with CSS using the fill: declaration on the fly.
[+] [-] yoz-y|9 years ago|reply
[+] [-] talmand|9 years ago|reply
I agree, it's like having to deal with images all over again; which we all know was a severe problem for the industry.
>> ??? what to do here to change the color ???
You see, that's because you picked one of the ways to use SVG that doesn't work the way you say you want it to. You are ignoring the other ways to handle the situation without the problem you're claiming. I would say you are being borderline dishonest just to make your false point.
As for the path idea, I don't think I would necessarily be against such a thing. But it would seem unwieldy with a complicated path.
[+] [-] z3t4|9 years ago|reply
[+] [-] ptrincr|9 years ago|reply
https://github.com/d3/d3/wiki/Gallery
At least this is what introduced me to working with SVG. As much as I like D3, mainly for charting, it's not the easiest thing to pick up.
[+] [-] tcfunk|9 years ago|reply
[+] [-] th0ma5|9 years ago|reply
[+] [-] igt0|9 years ago|reply
[1] https://github.com/WebKit/webkit/tree/master/Source/WebCore/... [2] https://developer.mozilla.org/en-US/docs/Web/SVG/SVG_animati...
[+] [-] amelius|9 years ago|reply
Yes, it would have been better if SVG was designed on top of something simpler; and this something simpler could be implemented by browser developers. Probably, such an approach is more secure too. But, I guess it is too late now.
[+] [-] legulere|9 years ago|reply
[+] [-] formula1|9 years ago|reply
- The first issue was the designer Im working with didnt know how to export to svg.
- Second problem is my svgs ended up with very weird numbers and groups. Such as the main groups offset was -60, 190 then another group to dlightly compensate. Then the paths themselves compensated further.
- Another issue is "cutouts" are nonintuitive for designers and also complex to reverse when they are curves.
- Another issue is linking and styling to an external svg. Despite you can put them in an image tag, it cannot be styled this way. If you put it inside a use tag, styling externally requires targeting ids.
- anothwr issue is that they dont follow the normal rules of width/height. By default they are 300x150 and takes a bit of patience to ensure they exist as 100% width (which I assumed was default)
Other than that, I am quite pleased with the format and am expecting great things for it!
[+] [-] Falkon1313|9 years ago|reply
Hand-writing a complex graphic is difficult! (ex: editing coastlines on a map) Unfortunately, current WYSIWYG editors produce bloated, illogical output full of bizarre measurement schemes, unnecessary translations, and incompatible proprietary garbage - sort of like the bad old days of Frontpage and Dreamweaver.
*There are also some quirks in both styling and scripting them (as others have mentioned, height is one, another is having to use NS versions of DOM functions instead of normal ones - but only sometimes).
Maybe by the time SVG turns 21, those things will be mostly sorted out. It's still in its awkward teenage years.
[+] [-] microcolonel|9 years ago|reply
[+] [-] CiPHPerCoder|9 years ago|reply
https://github.com/w3c/svgwg/issues/266
[+] [-] dsacco|9 years ago|reply
A practical demonstration of XSS in an SVG is the following:
I see this in the wild all the time, though these days it's becoming less harmful as more developers learn to host their images (and all user uploaded files, really) on a separate CDN.[+] [-] ogig|9 years ago|reply
If your app receives and parses svg server side you might have a hole there.
[+] [-] Pxtl|9 years ago|reply
Did anybody want this? I know I wanted a jpg of vector graphics - a resource-friendly small system for embedding vector graphics into things. Something where I don't have to worry about an image having an xss vulnerability. Something that degrades gracefully so it can still work in some form on an anemic piece of equipment.
But no. We throw bigger and heavier hardware at more trivial problems.
[+] [-] Chris_Newton|9 years ago|reply
Yes.
SVG is not a lightweight vector graphics format, which seems to be what you were hoping for. I agree that such a format would be useful as well.
However, for better or worse, web apps are a thing in 2016, and that means we need formats that lend themselves to programming and interaction. Having SVG do that for vector graphics is useful for much the same reasons as having HTML do that for text-based content and forms.
[+] [-] dietrichepp|9 years ago|reply
Resource-friendly for small systems--how would we reduce memory consumption? The alternative model for vector graphics is what, PDF or PostScript? They're not exactly models of restraint. SVG looks positively austere compared to PDF or PostScript.
The closest thing I can think of to your ideal "minimal binary" vector graphics is something like TTF, which is basically its own little nightmare compared with SVG. TTF has its own vulnerabilities, its own proprietary scripting system compiled to bytecode, et cetera.
For me, SVG is doing a great job of enabling really cool things like D3, and at the same time hammering more nails into the coffin that is Flash--something far more a resource hog than SVG. And we don't really need more 90s-era formats, we've got plenty of those, thank you very much. SVG is to images what HTML is to documents. You can build simple, static ones easily enough, and you can also make a little bit of magic happen if you throw in some JavaScript.
It looks like in the future we'll be embracing more binary systems. TLS, HTTP/2, and WebAssembly are some examples. But it took a long time to get the institutional expertise to invent such systems, and if we had rushed to use binary instead of text in the early days, we would have probably gotten it wrong in a bad way.
Besides... the hardware is getting bigger and faster anyway... we might as well deliver some good experiences with it. Most of your battery is probably going to power the backlight and GPS radio anyway.
[+] [-] userbinator|9 years ago|reply
[+] [-] Const-me|9 years ago|reply
If your software paints stuff using GDI or GDI+, you can use windows metafile images, EMF/EMF+/EMZ.
If your software paints stuff using Silverlight or WPF or WinRT, the XAML format has descent support for vector graphics. On WinRT, it’s even compiled to binary form, BAML, to save resources in runtime.
[+] [-] michaelchisari|9 years ago|reply
[+] [-] Animats|9 years ago|reply
If you need drawings with lines and boxes, Inkscape is very helpful. Most drawings in Wikipedia are in SVG, and many were drawn with Inkscape. You can update drawings in Wikipedia by bringing them into Inkscape and editing them, then checking them back in as an update. It's not a read-only notation, like Postscript.
Manually tweaking SVG text, though? Painful. It's encapsulated like XML, so you can, but you probably shouldn't. After you've done that, most draw programs won't be able to handle the fancy stuff. And really, drawing by typing text is like pounding a screw with a hammer.
[+] [-] the8472|9 years ago|reply
Well, you could embed xhtml into svg and use regular html styling and text layout instead.
[+] [-] contingencies|9 years ago|reply
[0] https://github.com/globalcitizen/svglover [1] http://love2d.org/ [2] https://github.com/fogleman/primitive [3] https://news.ycombinator.com/item?id=12539109 [4] Make it work first, then make it work fast.
[+] [-] niedzielski|9 years ago|reply
[0] https://en.wikipedia.org/wiki/User:Cmglee [1] https://upload.wikimedia.org/wikipedia/commons/0/06/Burj_Kha... [2] https://github.com/rndmem/ndice/blob/master/blend/d/render
[+] [-] iamleppert|9 years ago|reply
There is little provision for incremental rendering, and poor control and visibility of the internals of the rendering process. Once you dump your SVG to the browser, that's basically it. There's no way to find out what is going on.
It's really nice to just set a break point in your imperative Canvas code, or WebGL code and see exactly what is happening, and use all the standard debugging and profiling techniques. I have yet to see the same for SVG.
[+] [-] e1g|9 years ago|reply
D3 v4 provides all of its goodness in loosely coupled modules with clear boundaries, so you can use it for all heavy lifting that it's amazing at (layouts, animations, shapes), then setState() all over the place to reflect the results in the DOM. Performance wise, the only limits we are hitting are native SVG limits on the number of nodes.
Our visualisations are complex (science and finance, to an expert and expertly distracted audience), but no more complex than the rest of the app. React paradigm is predictable, well known, and has a deep user base to lean on. Performance and inspection tools are solid. And the only difference is that the render method has a <g> instead of a <div>.
[+] [-] edejong|9 years ago|reply
There are some caveats beginning users should be aware of. First of all, better forget multi line text or sophisticated text layout within the SVG. I still think that's really missing in the current specification. As a commute project I once wrote the dynamic programming layout of Knuth (used in TeX) for SVG and JavaScript, but it was slow and didn't allow for multi line selections.
Another problem is rendering speed. SVG renderers can be fast, but you have to know what can be optimized by the gpu and what requires the CPU.
[+] [-] comex|9 years ago|reply
Can't you do it by embedding an HTML document into the SVG with foreignObject?
(edit: corrected name)
[+] [-] th0ma5|9 years ago|reply
[+] [-] thom|9 years ago|reply
- Modularity is tough: you can nest <svg> or <g> elements with various transforms, but there's no first class layout concept.
- Pixel imperfections: browsers don't always render things 'nicely', and all sorts of horrid aliasing can happen.
- Styling options: all sorts of simple stuff like a double outline of a shape is really difficult (without extremely complex filters)
- Export: taking an SVG and exporting it as an image has lots of complications, especially with embedded fonts.
All that said, the output is mostly okay, and it's possibly the easiest graphical technology to integrate with React-style frameworks.
[+] [-] dietrichepp|9 years ago|reply
http://graphicdesign.stackexchange.com/questions/73601/is-th...
There are some interesting thoughts from nVidia on throwing GPU hardware at the problem. The specialized hardware on a GPU can handle coverage in a much more coherent way without paying a premium in processing and memory.
http://developer.download.nvidia.com/assets/gamedev/files/An...
[+] [-] taivare|9 years ago|reply
[+] [-] amelius|9 years ago|reply
Is something like this possible?
[+] [-] microcolonel|9 years ago|reply
[+] [-] emilsedgh|9 years ago|reply
And serve icon.svg dynamically.
As others have mentioned, only for colors, there are easier ways.
But using this technique you can do anything.
[+] [-] Chris_Newton|9 years ago|reply
This technique is quite limited, though, as unfortunately it only allows passing of a single colour as a “parameter” to the SVG. In some cases, currentColor is redundant, as often if you just draw something in the SVG without specifying any colour explicitly, it will inherit the colour by default anyway.
Beyond that, you’re probably into scripting the SVG and all the vaguely-documented, non-portable, security-nightmarish possibilities that offers. For example, suppose you embed an SVG in your HTML like this:
Then suppose the SVG file itself says something like this: In theory, this should log "green" to your console, assuming you load both the HTML and SVG from compatible origins. This is because window.frameElement should refer to the <object> element and thus should allow access to its attributes, containing HTML document, and so on. (Note that this only works with embedding; using <img> to load the SVG should block the scripting.)In practice, having just tried it in Chrome, Firefox and IE11, and loading from both a local disk and over HTTP, Firefox works in both cases, Chrome works over HTTP but blocks locally, and IE11 blocks in both cases (with window.frameElement being set to null in the blocked cases here). So sadly although this might be quite a useful technique if you can control your environment, it’s definitely not portable to all major browsers.
[+] [-] shurcooL|9 years ago|reply
That said, I _tried_ to use SVG for something as simple as displaying some multiline monospaced text with whitespace preserved, and found it's either really hard, or actually not possible (unless you position each glyph manually). Is that really the case?
[+] [-] mrb|9 years ago|reply
[+] [-] mojuba|9 years ago|reply
(Shameless self-plug as an example of an SVG-based GUI: https://itunes.apple.com/us/app/magnetola-vintage-cassette/i...)
[+] [-] tofflos|9 years ago|reply
[+] [-] gotofritz|9 years ago|reply
[+] [-] ygra|9 years ago|reply
[+] [-] robszumski|9 years ago|reply
- platforms like Twitter and Google Slides not accepting SVGs. I assume this is due to security concerns.
- Using SVGs on a website doesn't render with included WebFonts like normal text would. This leads to outlining text, which is a huge maintainability burden.
- Graphics programs have tones of SVG bugs. Even "leading" software like Illustrator and Sketch have a lot of bumps in the road.
Overall really excited about SVGs and use them as much as possible.
[+] [-] xnmvvv|9 years ago|reply
* SVG's performance degrades sharply after a few hundred objects, then you have to use canvas or WebGL, or prerender to images * browser differences
otherwise good
[+] [-] Hyperized|9 years ago|reply
[+] [-] flatline|9 years ago|reply