skip to Main Content

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?

2

Answers


  1. Maybe it is time to answer this question again. Contributions and edits are welcome.

    Accessibility

    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.

    Responsiveness

    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.

    Interaction

    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.)

    Form submission

    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.

    Conclusion

    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.

    Login or Signup to reply.
  2. You can build an entire website with SVG. I do it all the time, using Adobe Illustrator to create the pages.

    You can go to my site, ozake.com to see a nice example. Even that is pretty basic compared to what is possible.

    At first I did it all by hand, but the repetitive parts were annoying so I built a tool called Svija (svija.love, also SVG only).

    Essentially you just put an SVG inside of the html body tag.

    There are a few things to be aware of:

    Microsoft browsers need exact pixel dimensions to be specified or the SVG will be drawn at the wrong size.

    The Safari browser does not smoothly scale fonts (see my answer on this page). The consequence is that if you have two adjacent text blocks the space between them will vary randomly if the SVG size varies.

    If you want to have several SVG’s (one for the page, one for the footer, one for a menu, and one for a special event, for example), you need to be careful that the internal ID’s are different.

    Otherwise, a color style from the second SVG could be applied to the first SVG, with unpredictable results.

    You will probably need to update the font style definitions inside the SVG’s to make them work with web fonts. I use both Google Fonts and uploaded WOFF’s.

    You can make forms as a separate HTML layer based on the Adobe Illustrator system of coordinates. I just build the form in Illustrator, then copy the location and size of each element into absolutely-positioned HTML elements.

    It’s easier to build separate SVG’s for repetitive elements, as I alluded to above. Rather than having to copy a footer to each SVG, just make the footer a separate SVG that’s draw on top of the main page.

    I built Svija in part to make sure that each SVG has unique internal ID’s and to handle the font naming conversion.

    You can link to external fonts and images as you would in HTML.

    You can animate anything you want using GSAP.

    The site is listed normally by Google, but the text will be in the order that it appears in the SVG. You need to pay attention in constructing the SVG if this is a priority.

    To handle accessibility, I put the page text in a separate DIV before the SVG. Theoretically, a page reader should read the text inside an inline SVG but I have been unable to find out if this is the case.

    I don’t want to come across as trying to push my project. It’s totally possible to do it all by hand.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search