Hacker News Reader

Comment by oefrha | Hacker News Reader

By far the biggest advantage of SVG on the web is DOM integration, thanks to its choice of XML. This enables, among other things,

- Trivial adaptive styling: the simplest case would be matching color of surrounding text;

- Easy and relatively cheap dynamic updates to individual components, trivially integrated with any DOM-manipulation tech, including declarative frameworks big and small.

I don't see a binary format easily replicating those.

Edit: Of course it's okay to have more opaque binary formats.

View on HN

SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly, which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer.

SVG is so bad people have been using fonts instead (which are binary).

And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway, the binary vs text argument here seems totally irrelevant.

> you need to embed it directly.

Guess what “DOM integration” means.

> SVG is so bad people have been using fonts instead

Icon fonts have been out of fashion for so long I almost suspect you time traveled from the past.

> Guess what "DOM integration" means.

Does it mean unusably inconvenient? Because that's what I call having to embed SVGs just so CSS works with them.

Hold up. Are you blaming SVG because you don't know the <object> tag exists? I mean, yeah, you're right that CSS won't come through with an <img> tag. It will with <object> though.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ob...

No I am not.

https://stackoverflow.com/a/34902454/265521

Ah, I misunderstood what you were trying to accomplish. Yes, it makes sense that you have to embed the SVG in your HTML doc. SVG isn't an image format; it's a document format just like HTML is. Embedding the SVG puts it in the same document context as the HTML and therefore the same styling context.

Would you expect a parent's CSS to affect HTML in an iframe, a separate document context? That would be confusing behavior to be sure. Side effects galore.

No I wouldn't, because a) iframes are used to provide isolation, and b) nobody really wants that.

The use case for styling external SVGs with CSS is waaay more obvious. We should at least have the option to do it, even if it isn't enabled by default.

Just out of curiosity, what has replaced icon fonts?

Graphics (typically vector), GitHub has a good writeup on the why

* font rendering issues

* rendering improvements

* accessibility

* ease of authoring

* can be animated

https://github.blog/2016-02-22-delivering-octicons-with-svg/....

https://speakerdeck.com/ninjanails/death-to-icon-fonts

Font folks also really underestimated how much people like having access to graphics with more than one color.

They didn't: https://fonts.google.com/knowledge/introducing_type/introduc... (is that a good idea for icons, not sure though)

Are you really going to compare a technology like SVG that was supported by IE9 (and lower with a plugin) with one only just supported by the Blink engine May, 2022 in Chrome 101?

For all intents and purposes with regard to web development, fonts have been monochromatic (except for emojis). Any with sufficient knowledge gathered over decades can write/edit an SVG in the editor of their choice, graphical or textual.

How does one edit their own color font? Can you do it in a text editor? Do most font editing programs support it? Or were you speaking of fonts purely as a consumer rather than a producer?

I write SVG by hand every day, but I imagine to be the 0.1% you are talking about. The ability to write simple or complex graphics in text form both inside HTML or CSS is a feature, and an incredibly powerful one.

The only way to practically interact with SVG content [...] you need to embed it directly

Right, and this is actually pretty common -- you can use <svg> tags directly in JSX, and you can set up a build pipeline that lets you import .svg files directly into your .jsx/.tsx.

It's useful because you can do things like animate your SVG using CSS, driven from the JS/JSX code.

Most of the time (and speaking from experience here), any “interaction” with inlined SVGs happens at compile time, setting the size or colors. Animating opacity, scale is done via CSS on the container element.

And for complex animations you resort to Lottie. So interacting with SVG via its DOM API is incredibly rare.

No I don't agree. Simple things like styling the inside of the SVG or animating the colors is pretty common and does not require reaching for Lottie. I don't think Lottie is all that commonplace outside of very large codebases in borderline enterprise environments.

You're probably right in general, but I had a need just the other day to animate something other than opacity and scale. I realised I would need to inline the SVG to make it work, and it was pleasantly straightforward.

> SVG is firewalled off from js and css regardless of how you use it. The only way to practically interact with SVG content (i.e. make it actually more useful than a jpg) you need to embed it directly

You're contradicting yourself here.

> ... which requires stripping the `<?xml` and `<!DOCTYPE`, which requires an xml parser/serializer

That doesn't make sense either. Removing the XML declaration and the doctype declaration can be done using the same editor you're using for your HTML at hand - unless you're referencing the SVG as external resource via href, and then you don't need to remove it all. XML and doctype declaration aren't needed for XML conformance anyway, and your tool should offer an option to export without these.

Note according to the WHATWG HTML spec (redacted snapshots of which used to be known as W3C HTML 5.x until recently) when used embedded in HTML, SVG content is actually parsed using HTML/generic SGML rather than XML rules. For example, unlike in XML, element/tag and attribute names can be written in any mix of lowercase/uppercase chars, etc.

Are you sure you know enough about web development to make these claims?

All of my data viz code is React-controlled SVGs, for instance. I was able to implement generic zoom and pan on top of this. Also things like nested graphs look good in SVG

> SVG is firewalled off from js and css regardless of how you use it.

That's a weird claim, since most of my SVG customizations are done using CSS.

> SVG is so bad people have been using fonts instead (which are binary).

No they're not, SVG is far more popular than icon fonts, which has been in steady decline for years.

> And 99.9% of people who use SVG are doing it with illustrator or inkscape anyway

False again. SVG is a popular export format for myraid of desktop, mobile & online design & publishing tools and presentation software which I've used over the years, none of which were Illustrator or Inkscape. I've also hand edited lots of SVGs to customize it to look how I want, which isn't feasible for Icon fonts.

Reply on news.ycombinator.com