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?
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.
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.
Related
<nav> typically has <a> elements inside it, but is it required? I have a radio button form whose purpose is akin to navigation. It doesn't navigate to other pages on the Internet, but instead changes the visibility of elements within the body of the HTML document (like a carousel).
Thanks! I've been wrestling with semantic markup tonight!
tl;dr: No, the nav element requires links (but not necessarily a elements).
W3C’s HTML5 defines the nav element like this:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.
By default, a radio button doesn’t link to a part within the page. In your case, it changes the visibility of an element on the page. So it’s not appropriate to use the nav element for this purpose (unless, maybe, changing the radio button focuses the changed element; but that behaviour might be bad for usability).
The whole point of semantics, is that when viewed in an entirely different light, it's still readily clear in how to derive meaning and relational context from the content.
A web browser will parse your HTML out of the Dom after every load or change, and construct an opinion based on that about the content. The browser will keep this handy to itself internally in case it needs it later to assist it with difficult judgement calls should it be asked to perform a seemingly complex operation.
For example, someone who has really poor eyesight might enable an accessibility feature on their mobile device that tacks on a variety of different visual styles adding a great deal of visual emphasis to interactible elements they can touch, depending on the type of interaction. This could be something like a bright color coated and outlined overlay on top of elements, perhaps something like cyan for multimedia controls, yellow for form elements, and magenta for navigation points. This feature would have to work on any and all possible content which the browser will ever render, and so what you've got is a hidden under the hood runtime script that the browser is using to dynamically parse what ever it's loaded in order to construct some sort of opinion which it can lean on exorcise what will hopefully be good judgement. So no matter how clear your navigation might seem visually to someone with great eyesight, this is why semantics are such a big deal and why it's so important we continue to make efforts to use them correctly, as here you have a machine alternatively parsing your source code because it has zero comprehension of it's otherwise visual context.
When it comes to accessibility, browsers are much more complex in forming their opinions than just simply parsing the Dom. In a scenario such as this example, and the code you're wanting to write, wrapping your navigation elements in a nav tag should properly assist the browser into making the right call. Even if they're not link tags, the browser is going to take note of any elements inside of a nav tag witch active event listener handles items like click and similar.
As another user mentioned, semantics is all about judgement. There are countless other ways which good semantics play a role into good development, dry code and easier maintainability being my two favorites. There are no hard lines for "can do" and "can't do", but practicing good semantics is still pretty easy to do regardless. Just continually ask yourself these couple of questions about your core content-
• If someone or something tried to use this in ways which I'm not explicitly building in targeted functionality for, do I think it will be able to understand what content is what and the associated intents well enough to be successful at what ever is being attempted?
• If I was to refactor or repurpose any of this later, is there a clear separation of content, logic, and style? Is my content clean, and meaningfully distinguished? Is it so clean and ready, that I can just rip it out and drop it into something new with little or no change? Essentially, how portable is this content? Is it plug and play level portable? And if not, could it be made more portable with better semantics?
Practice developing with proper semantics using those couple of core guidelines, and you'll almost always be perfectly fine.
Just to make sure I've directly addressed your question- Yes. What you've done is "okay", and "semantically legal" 🙂
Google suggests to use very important CSS inline in head and other CSS inside <noscript><link rel="stylesheet" href="small.css"></noscript>.
This raises few questions in my mind:
How to prioritize CSS in two files. Everything for that page looks important. Display, font etc. If I move it to bottom then how it helps page render. Wont it cause repaint, etc?
Is that CSS is required after Document ready event? Got it from here.
How 'CSS can' go inside <noscript></noscript>, which is for script? Will it work when JavaScript is enabled? Is it browsers compatible?
Reference
Based on my reading of the link given in the question:
Choose which CSS declarations are inlined based on eliminating the Flash-of-Unstyled-Content effect. So, ensure that all page elements are the correct size and colour. (Of course, this will be impossible if you use web-fonts.)
Since the CSS which is not inlined is deferrable, you can load it whenever makes sense. Loading it on DOMContentReady, in my opinion, goes against the point of this optimisation: launching new HTTP requests before the document is completely loaded will potentially slow the rest of the page load. Also, see my next point:
The example shows the CSS in a noscript tag as a fallback. Below the example, the page states
The original small.css is loaded after onload of the page.
i.e. using javascript.
If I could add my own personal opinion to this piece:
this optimisation seems especially harmful to code readability: style sheets don't belong in noscript tags and, as pointed out in the comments, it doesn't pass validation.
It will break any potential future enhancements to HTTP (or other protocol) requests, since the network transaction is hard-coded through javascript.
Finally, under what circumstances would you get a performance gain? Perhaps if your page loads a lot of initially-hidden content; however I would hope that the browser itself is able to optimise the page load better than this hack can.
Take this with a grain of salt, however. I would hesitate to say that Google doesn't know what they're doing.
Edit: note on flash-of-unstyled-content (abbreviated FOUC)
Say you a block of text spanning multiple lines, and includes some text with custom styling, say <span class="my-class">. Now, say that your CSS will set .my-class { font-weight:bold }. If that CSS is not part of the inline style sheet, .my-class will suddenly become bold after the deferred loading has finished. The text block may reflow, and might also change size if it requires an extra line.
So, rather than a flash of totally-unstyled content, you have a flash of partly-styled content.
For this reason you should be careful when considering what CSS is deferred. A safe approach would be to only defer CSS which is used to display content which is itself deferred, for example hidden elements which are displayed after user interaction.
Disclaimer
I realize that given the absurdity of the title, this sounds like a troll. However, it's a genuine question. My background involves OpenGL / x86 assembly. I've recently started learning web programming. I really like SVG + CSS, and was wondering -- why do people not design entire webpages in SVG?
Context
SVG provides beautiful primitive: quadratic + cubic bezier curves; lines + filling -- all as vector graphics
SVG provides text
SVG provides affine transformations
Questions
Are there examples of people designing entire websites as a giant SVG file?
If not, what the limitations?
Are there performance hits when using SVG primitives as opposed to divs/tables?
It is possible; for example you can embed HTML fragments in SVG documents in order to get things like hyperlinks.
However, there are some significant disadvantages, at least at present:
Current web browsers treat SVGs as images, and may not present as good a UI to users. For example, I think Firefox doesn't allow the user to select text in SVG files.
You lose separation of content and presentation. While SVG does use CSS, and you can in principle maintain the separation if you edit by hand, you are probably designing the layout together with the content. This has several drawbacks:
As a corollary, it's harder to adapt the resulting page to other formats. Particularly:
What's the behavior when the text size is changed? the document is printed? the window is resized? It's hard to design a complex drawing that supports reflow nicely (and if your drawing isn't complex, you may as well just use HTML+CSS).
Screen reader support: since order is not clear (below), screen readers may give incomprehensible, scrambled output. More basically, screen readers may assume the SVG is an image and not even try to read the text.
SVG is exclusively based on XML, and hence requires pretty strict adherence to the rules. With (X)HTML, you have the option of using the plain HTML serialization. Then many of these rules are relaxed, and browsers are more robust if you feed them bogus input (as opposed to an XML PARSING ERROR if you have a single misplaced >).
Current search engines probably won't index your pages (they'll just treat them as monolithic images). Never mind
Order of the content is not clear. Tools like Inkscape don't need to care about the order elements are output in, as long as they are positioned correctly in the output and the z-order is correct. But if you're making a web page, this does matter, because screen readers don't know for sure which element is semantically first. This isn't an issue if you're only editing the SVG by hand, but the usual SVG tools may scramble your order. With HTML, it's generally clear.
It's difficult to implement fragment identifiers (#id_of_some_element at end of URL) well. The presentation program below uses them, but I think it depends on Javascript (bad for search engines and people with javascript disabled). (I'm not sure about this one)
*̶ ̶I̶t̶'̶s̶ ̶d̶i̶f̶f̶i̶c̶u̶l̶t̶ ̶t̶o̶ ̶c̶o̶n̶v̶e̶r̶t̶ ̶t̶o̶ ̶t̶e̶x̶t̶ ̶(̶f̶o̶r̶ ̶s̶e̶a̶r̶c̶h̶ ̶e̶n̶g̶i̶n̶e̶s̶,̶ ̶s̶c̶r̶e̶e̶n̶ ̶r̶e̶a̶d̶e̶r̶s̶,̶ ̶c̶o̶p̶y̶-̶a̶n̶d̶-̶p̶a̶s̶t̶e̶,̶ ̶e̶t̶c̶.̶)̶,̶ ̶p̶a̶r̶t̶i̶c̶u̶l̶a̶r̶l̶y̶ ̶w̶h̶e̶n̶ ̶g̶e̶n̶e̶r̶a̶t̶e̶d̶ ̶w̶i̶t̶h̶ ̶g̶r̶a̶p̶h̶i̶c̶a̶l̶ ̶t̶o̶o̶l̶s̶.̶ ̶F̶o̶r̶ ̶e̶x̶a̶m̶p̶l̶e̶,̶ ̶h̶t̶t̶p̶:̶/̶/̶w̶w̶w̶.̶a̶f̶r̶o̶k̶a̶d̶a̶n̶s̶.̶c̶o̶m̶/̶P̶a̶g̶e̶_̶0̶1̶.̶s̶v̶g̶ ̶s̶h̶o̶w̶s̶ ̶u̶p̶ ̶i̶n̶ ̶G̶o̶o̶g̶l̶e̶ ̶a̶s̶ ̶̶D̶A̶N̶S̶E̶ ̶E̶T̶ ̶M̶I̶S̶E̶ ̶E̶N̶ ̶F̶O̶R̶M̶E̶ ̶B̶I̶E̶N̶V̶E̶N̶U̶E̶ ̶D̶ ̶a̶ ̶n̶ ̶s̶ ̶e̶ ̶r̶ ̶p̶o̶ ̶u̶ ̶r̶ ̶c̶é̶ ̶l̶ ̶é̶b̶ ̶r̶ ̶e̶ ̶r̶ ̶l̶ ̶a̶ ̶v̶ ̶i̶e̶.̶ ̶E̶ ̶n̶ ̶v̶e̶ ̶l̶ ̶o̶p̶p̶ ̶é̶ ̶e̶ ̶d̶ ̶e̶ ̶t̶ ̶a̶ ̶m̶ ̶b̶ ̶o̶ ̶u̶r̶ ̶s̶ ̶i̶n̶ ̶d̶o̶ ̶c̶ ̶i̶l̶ ̶e̶ ̶s̶ ̶e̶ ̶t̶ ̶i̶ ̶n̶ ̶c̶e̶ ̶s̶s̶ ̶a̶ ̶n̶t̶s̶̶.̶ ̶I̶n̶ ̶c̶o̶n̶t̶r̶a̶s̶t̶,̶ ̶e̶v̶e̶n̶ ̶c̶r̶a̶p̶p̶y̶ ̶W̶Y̶S̶I̶W̶Y̶G̶ ̶H̶T̶M̶L̶ ̶g̶e̶n̶e̶r̶a̶t̶o̶r̶s̶ ̶w̶o̶n̶'̶t̶ ̶s̶p̶l̶i̶t̶ ̶u̶p̶ ̶r̶u̶n̶s̶ ̶o̶f̶ ̶t̶e̶x̶t̶ ̶l̶i̶k̶e̶ ̶t̶h̶a̶t̶.̶
Something to consider is that it is possible to embed SVG elements in XHTML and HTML 5, so you get some of the benefits without throwing off browsers/search engines.
Existing usage
I've heard of its use for presentations (which are closer to drawings in some respects, so some of the above drawbacks don't apply):
"Jessyink is a JavaScript that can be incorporated into an Inkscape SVG image containing several layers. Each layer will be converted into one slide of a presentation."
Another implemetation; info and an example
It is really cool to think that an .svg image file can be used to create a webpage without knowing any html. Considering how messy html standards are, to be able to use an Inkscape .svg file might be a lot easier for people who are naturally artistic. When you think about Inkscape and Openclipart being mostly useful for people who are doing Desktop Publishing, Scrapbooking etc to be able to export a webpage directly from Inkscape would be a powerful tool.
As for 600 years of typesetting we are in the 21st century, and media publishing doesn't have to conform to medieval ideas of formatting. Typesetting does have its palace but we are talking about a powerful experiment that could help 'average Joe' users turn their art into webpages without knowing CSS or HTML.
For reference, the Opera team has done quite a lot of work with using SVG for web pages - http://dev.opera.com/articles/svg/
There is a platform designed specifically to create SVG-based websites: Svija (disclaimer: it is my project).
The advantage of an SVG website is that you can literally do anything you want; you're not limited to rows of rectangles as you are with HTML.
The big issue is accessibility. Right now SVG text is crawled by Google but it can easily be out of order depending on the source document. Also semantic information that would normally be conveyed by HTML tags (H1 is more important than P) is nonexistant.
The main things to realize are that:
you can use external fonts and images in an SVG file
the width and height have to be specified correctly for Microsoft's browsers to display the SVG at the correct size
if you combine different SVG files, conflicting ID's can cause CSS styles to be misapplied
The only program that I have found that can correctly link to images and fonts is Adobe Illustrator. There is a list of all the programs I have found that can create SVG files here, with some information about which programs support which features.
Actually, there are pages that rely heavily on SVG; using a Javascript library such as Raphaël is a common way to do it. Paper.js is also worth a peek, although they chose not to use SVG.
You can indeed make entire web sites with SVG, I've been doing it for years. If you're willing to change how you look at designing pages (Think Cards) then it's just a matter of trial and error.
I've been learning (X)HTML & CSS recently, and one of the main principles is that HTML is for structure and CSS for presentation.
With that in mind, it seems to me that a fair number of images on most sites are just for presentation and as such should be in the CSS (with a div or span to hold them in the HTML) - for example logos, header images, backgrounds.
However, while the examples in my book put some images in CSS, they are still often in the HTML. (I'm just talking about 'presentational' images, not 'structural' ones which are a key part of the content, for example photos in a photo site).
Should all such images be in CSS? Or are there technical or logical reasons to keep them in the HTML?
Thanks,
Grant
If an image is "content" say in a newspaper article, the editorial image, then use img tag. If it is part of your UI, theme or skin or whatever the name is, then yes put it CSS.
Suggested readings
Designing with Web Standards (Zeldman)
Bullet Proof Web Design (Dan Cederholm)
CSS Mastery (Andy Clark, Andy Budd, Cameron Moll)
One reason to put those images in CSS might be to serve different browsers from the same web site, just by changing the CSS: for example, if you detect a mobile/embedded/pocket browser you could give them the same HTML but with a CSS that doesn't include images.
I put them to CSS if possible. One reason is that I think they belong there like you mentioned and the other one is the possibility to use sprites. This can reduce the loading time of your page significantly.
The src property of an img tag is required according to HTML 4.01/XHTML 1.0 DTD. That is why it should always be included in the HTML.
You can specify it in the CSS for skining purposes, but most images in most cases are static and non changing so putting it in CSS is an unecessary step.
Well, it depends. For example, if you want to do some effects when the mouse is over an image, it must be in the HTML. When you put the image in the HTML you can positionate it more freely than in CSS. Also, as far as I know, CSS included images are not crawled (You can have interest in have your company's logo crawled by searchers).
If you think about accesibility, the HTML embedded images can have an alt and title information. So, for example, when you put the mouse over the logo of your company, the browser could show the motto of your company if you embed it with title="motto" attribute in the img tag. You can't do that with CSS.
Also people are used to put images in the HTML not the CSS and behaviours are a hard thing to change.
In conclussion, depending of your needs, CSS isn't flexible enough to fit your needs and you should put the images in the HTML. But if CSS fits your needs for UI images, then CSS is better idea.
Sometimes, loading UI images using CSS, also prevents the users from downloading your UI images to their drives, while saving a page.
But of course there are other ways to save them, but just a point to add.
And browsers tend to prioritize CSS more than HTML, so loading images through CSS might be a little faster compared to HTML.
I have an app that reprocesses HTML in order to do nice typography. Now, I want to put it up on the web to let users type in their text. So here's the question: I'm pretty sure that I want to remove the SCRIPT tag, plus closing tags like </form>. But what else should I remove to make it totally safe?
Oh good lord you're screwed.
Take a look at this
Basically, there are so many things you want to strip out. Plus, there's stuff that's valid, but could be used in malicious ways. What if the user wants to set their font size smaller on a footnote? Do you care if that get applied to your entire page? How about setting colors? Now all the words on your page are white on a white background.
I would look into the requirements phase again.
Is a markdown-like alternative possible?
Can you restrict access to the final content, reducing risk of exposure? (meaning, can you set it up so the user only screws themselves, and can't harm other people?)
You should take the white-list rather than the black-list approach: Decide which features are desired, rather than try to block any unwanted feature.
Make a list of desired typographic features that match your application. Note that there is probably no one-size-fits-all list: It depends both on the nature of the site (programming questions? teenagers' blog?) and the nature of the text box (are you leaving a comment or writing an article?). You can take a look at some good and useful text boxes in open source CMSs.
Now you have to chose between your own markup language and HTML. I would chose a markup language. The pros are better security, the cons are incapability to add unexpected internet contents, like youtube videos. A good idea to prevent users' rage is adding an "HTML to my-site" feature that translates the corresponding HTML tags to your markup language, and delete all other tags.
The pros for HTML are consistency with standards, extendability to new contents types and simplicity. The big con is code injection security issues. Should you pick HTML tags, try to adopt some working system for filtering HTML (I think Drupal is doing quite a good job in this case).
Instead of blacklisting some tags, it's always safer to whitelist. See what stackoverflow does: What HTML tags are allowed on Stack Overflow?
There are just too many ways to embed scripts in the markup. javascript: URLs (encoded of course)? CSS behaviors? I don't think you want to go there.
There are plenty of ways that code could be sneaked in - especially watch for situations like <img src="http://nasty/exploit/here.php"> that can feed a <script> tag to your clients, I've seen <script> blocked on sites before, but the tag got right through, which resulted in 30-40 passwords stolen.
<iframe>
<style>
<form>
<object>
<embed>
<bgsound>
Is what I can think of. But to be sure, use a whitelist instead - things like <a>, <img>† that are (mostly) harmless.
† Just make sure that any javascript:... / on*=... are filtered out too... as you can see, it can get quite complicated.
I disagree with person-b. You're forgetting about javascript attributes, like this:
<img src="xyz.jpg" onload="javascript:alert('evil');"/>
Attackers will always be more creative than you when it comes to this. Definitely go with the whitelist approach.
MediaWiki is more permissive than this site; yes, it accepts setting colors (even white on white), margins, indents and absolute positioning (including those that would put the text completely out of screen), null, clippings and "display;none", font sizes (even if they are ridiculously small or excessively large) and font-names (even if this is a legacy non-Unicode Symbol font name that will not render text successfully), as opposed to this site which strips out almost everything.
But MediaWiki successifully strips out the dangerous active scripts from CSS (i.e. the behaviors, the onEvent handlers, the active filters or javascript link targets) without filtering completely the style attribute, and bans a few other active elements like object, embed, bgsound.
Both sits are banning marquees as well (not standard HTML, and needlessly distracting).
But MediaWiki sites are patrolled by lots of users and there are policy rules to ban those users that are abusing repeatedly.
It offers support for animated iamges, and provides support for active extensions, such as to render TeX maths expressions, or other active extensions that have been approved (like timeline), or to create or customize a few forms.