Menu
I've been using SVGs for a multitude of things and I was able to get the exact result I was looking for. This got me wondering why we can't build entire websites with them...
I don't mean like replace index.html with index.svg. More like having the basic HTML framework (for meta tags, styelsheets, scripts, etc.) and then giving <body> a single inline <svg> child where everything else happens. (text, layout, scaling, etc.)
My initial assumptions are that the website will fall short when it comes to form functionality, SEO, and accessibility. But then again if those can somehow be circumvented, then powerful SVG features can be used to render lightweight graphical effects that can effectively scale to any device dimensions.
Has this been attempted before and what are the potential pitfalls of "replacing" HTML with SVG? Should form functionality, SEO, and accessibility be a valid concern?
587
SVG files contain enough information to display vectors at any scale, whereas bitmaps require larger files for scaled-up versions of images — more pixels use up more file space. This is good for websites because smaller files load faster on browsers, so SVGs can increase overall page performance.
Speed. The implementation of Scalable Vector Graphics (SVG) in web design is fast. Raster images like JPEGs and PNGs typically have very large file sizes, slowing down websites as a visitor's browser tries to download all that information. SVGs, on the other hand, have much smaller file sizes and load much quicker.
Because SVG files are vector graphics (as opposed to pixel-based raster images), you can resize them without losing image quality. This is especially helpful when you are creating responsive websites that must look good and work well across a wide range of screen sizes and devices.
Maybe it is time to answer this question again. Contributions and edits are welcome.
SVG content is visual content. That in itself poses restrictions on accessibility. Nonetheless, the upcoming SVG2 spec has a paragraph on ARIA attributes that tries to give at least a bit of assistance. If you look more closely, you will find that for example a graphics primitive will get a default aria-role="graphics-symbol", which is not really helpful.
Whether screen readers implement any of this I don't know.
SVG gives you the opportunity to add <title> and <desc> tags anywhere. But the standard semantics that HTML5 offers through tags are lost. No header, no sections, no TOC or navigation. Try to imagine what the Firefox Reader View could make out of such a page: nothing.
Even linking to partial content of a page is difficult. While the spec is there, the semantic remains constricted: do you really want to highlight a link target by scaling it up to cover the whole viewport?
SEO in the end is just a specialized aspect of accessibility. Having an HTML <header> segment, a few things might be possible. Maybe someone else can comment on what Google implements.
Problems start with the current inability of automatically line-wrapping text. Layout facilities are still a future project without working implementations. (While Firefox knows CSS inline-size, it is only implemented for HTML and does not work in SVG.)
CSS has put a lot of effort into providing layout mechanisms like flex and grid layout. In SVG, you lose all these techniques for reordering content in favor of simple automatic scaling.
Text input is a solvable problem. You can use HTML inputs wrapped in a <foreignObject> tag, or you can build text input widgets from scratch by capturing keyboard input into a <text> element.
For most other forms of user input SVG might even be the superior platform. For example, clicking on/touching something to mark it and dragging it around/swiping it turn out to be only two aspects of basically the same interaction.
Especially Web components are the perfect complement to SVG for building interactive widgets. (Despite you still have to go through polyfills for compatibility with Firefox.)
While HTML form submission for initiating HTTP requests might be absent, the advent of single-page apps has shown that it is possible to employ XHR requests instead.
If your content depends on or benefits from the standard semantics HTML5 offers, SVG is clearly not appropriate.
If you need to change the layout of your page in a responsive way, SVG will not be helpful.
SVG gives a lot of additional possibilities for creative, visually-oriented user interactions. As long as you find fallback solutions for visually-impaired users, your page will gain from it.
Overall, SVG gives you creative possibilities for specialized areas and widgets on your page, but falls short on the basic semantic questions a web page has to answer: How does your page relate to other resources on the web? What on your page is content, what is meta information, what is decoration?
The best of both worlds is to be gained by using a mix-and-match approach: structure your page with HTML, decorate it with SVG graphics, and build interactive/animated widgets with SVG and maybe Web Components.
96
answered Sep 20 '22 16:09
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
