Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Why not use SVG for everything?
13 points by kizer on June 13, 2020 | hide | past | favorite | 16 comments
Some context: It seems like web development is stuck in a frustrating limbo between utilizing HTML presentationally, while trying to maintain a balance with ARIA/accessibility and so-called semantic markup. There's a dissonance that bugs me - and of course call out any ignorance or insularity here - but I really wish there were a purely graphical/animated layer, with a semantic construction of sorts "super-imposed" on top to ensure accessibility and bot-digestible metadata.

Brings me to the title. Aside from wrapped text, this graphical layer could be pure SVG + CSS&JS. Why constrain designers to little CSS hack triangles and circles when there's an almost limitless vector graphics technology available instead?

I predict even with Houdini, CSS won't be rich enough to eliminate presentational markup for complex web applications. I know about role="presentation", but that seems to be an awkward compromise to avoid an explicit separation of concerns:

'Inspect element' any sophisticated web app and you'll see divs inside of divs inside of divs with class="color-blue border-2px border-gray background-number-seven". Slight exaggeration, but the separation of concerns doesn't exist.

I know the spirit of the web is "hackish" in that the standard quo is more of a gradual, messy evolution that gets there eventually rather than giant leaps which may not "stick the landing". However, to me it appears that some organization of _presentational_ aspects in particular is really needed. I know WebComponents, Houdini, and other "rationalize the platform" efforts' goals include this in part, but it doesn't seem like a nice graphical/animation layer which would sidestep DOM performance issues is in the cards.

This was off the top of my head, but I hope I got the gist across. I welcome any feedback.



Have you ever read or attempted to implement a portion of the SVG specification?

It's absurdly complex, and there is little guarantee that the SVG spec is implemented completely and identically in different environments. I know of several native GUI SDKs that do not support a large portion of the spec.

Even something that should be easy like doing a wireframe or mockup in Sketch, exporting to SVG, then displaying that exported SVG in a browser on the same machine can display jarring errors in the rendered image.

And most of the cool shit in SVG - like embedded JS and the filters spec - are where those issues rear their heads.

What I'm saying is that SVG is as much a shitshow as HTML. It's just HTML with additional drawing semantics anyway.


Ah, thanks for the info. I was imagining just manipulating it in the browser via JS; no direct export, but a re-implementation of a mock-up, perhaps.

I think it could be utilized more often for simple presentational components, such as dialogue boxes or modals, or for various bezier-piece paths.


I've always thought SVG should be more a part of things, but I think it's not as mature. If there were more SVG authoring tools it might help (symbolic ones).

But it is pretty cool:

https://upload.wikimedia.org/wikipedia/commons/6/6c/Morphing...

From: https://en.wikipedia.org/wiki/SVG_animation


Interesting that the performance of that demo is awful in fullscreen on my retina iMac in both chrome and FF; like, 3 FPS. Resizing downwards makes it run smoothly.


You're right. I tried firefox and it didn't get the screen size right either - clipping the edges.


I 'inspect-element'd some random pane on Facebook: https://imgur.com/a/qecS7gJ


That's intentional, they do it both to stop adblockers from working and to fight scrapers. Last I checked, the mangling algorithm switched up fairly regularly but I don't use Facebook much these days so it might have changed.


It might be easier to screen capture the page and extract text via OCR than deal with a constantly shifting DOM, since at least the former (screenshots) will remain more likely static.


Ahh, OK. I remember reading about that vaguely. Coincidence I chose FB. I know Google's DOM is equally unintelligible.


> Aside from wrapped text, this graphical layer could be pure SVG + CSS&JS. Why constrain designers to little CSS hack triangles and circles when there's an almost limitless vector graphics technology available instead?

Could you expand on what you'd gain that isn't being done already? I'm not following what you mean here.

Web developers already use SVG for complex vector illustrations + some JS or CSS to animate the SVGs, coupled with CSS for simple shapes (like circles + rounded rectangles with shadows), and CSS for responsive layouts (SVG doesn't have anything similar to CSS in terms for responsive logic or layout logic as far as I know).

This works well enough, and for example you can replicate most UIs you'd see on different platforms without getting too crazy. I feel most UIs people want to build just really are composed of mostly rectangles, oval and circle, some layering and some shadows - CSS alone is decent at this.


Good point on responsiveness; perhaps layout could be HTML. I guess this is a bit black and white, but I’d rather embrace a single tech entirely and simplify the whole design, interactivity, etc process. Then tooling could be more easily reused; libraries would generate potentially complex SVG path vector components that would take a bunch of CSS hacks and :before/divs on divs.

To address the second paragraph; I have a feeling that the limitations of HTML/css influence to a degree some of the result UI design. If you look at some stellar native UI’s, there are many little details and also more complex interactions which would be very bulky to implement in a web app, with probably prohibitively bad perf. It’s hard to think of examples, but maybe the JetBrains IDE’s, CAD tools, MS office (their online versions use almost all SVG, at least in PowerPoint).


You can build websites already in SVG with no HTML — not even a wrapper page. You just need to configure the web server to serve SVG instead of HTML by default. e.g. in Apache:

  DirectoryIndex index.svg index.html ...
You can also embed HTML inside SVG if you want, or HTML in SVG in HTML. I've only tried it for small demos and not seen it (SVG-only sites) used in the wild, but it does work.


Additional discussion on this topic from ~2 weeks ago: https://news.ycombinator.com/item?id=23385380


Wow! Developers' brains are really in-sync, it appears.


Are you saying that "Browser DOM is the root of all evil." ?


...is that the title of something on the front page right now? Seriously asking; haven't checked, lol.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: