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.
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.
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.
And for complex animations you resort to Lottie. So interacting with SVG via its DOM API is incredibly rare.
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.
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.
Does it mean unusably inconvenient? Because that's what I call having to embed SVGs just so CSS works with them.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ob...
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.
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.
* font rendering issues
* rendering improvements
* accessibility
* ease of authoring
* can be animated
https://github.blog/2016-02-22-delivering-octicons-with-svg/....
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?
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.
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