I recently fount this project https://github.com/flipboard/react-canvas which uses canvas to render the whole page on mobile. The result is astonishing and performs really well. By the way, from what I know, content inside canvas elements is not seen by search engines. What is the correct way to index this content?
Traditionally (with Flash/Silverlight sites) it has has been done by feeding search engines with alternative content that displays indexable text. I'm sure you can do the same with the canvas element.
The easiest approach being:
<canvas>This is what search engines actually see</canvas>
Related
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.
I have a div with some sentences that I don't want to be indexed by search engines.
Is it possible to somehow hide this from Google in a way?
I thought about using frames, and having the site within the frame being blocked by robots.txt, but I've never liked the idea of using frames.
Are there other options?
Technically, you could use iframe and put <meta name=robots content=noindex> into the iframed document. Using suitable attributes and CSS, you can make the iframed document appear as part of the page, mostly, though you would still need to reserve some fixed area for it.
Or you could generate the div with JavaScript, thought then it would not be seen when JavaScript is disabled. Note that search engine bots may execute JavaScript code and might thus “see” the generated content, though I would not expect that to happen now or in the near future.
If the content is text, without internal markup or images etc., you could have an empty div with a CSS rule that adds content using the :before pseudoelement and content property. This would fail for users with CSS disabled or with an aggressive user style sheet, and search engine bots might some day start interpretign CSS.
There might be trickier methods, too, but as a whole, there is no good way I think. It’s probably more useful to consider why you would want to prevent from finding the page on the basis of its content. As a tool for hiding information, it would be inefficient.
You could create images from the sentences, then the text wouldn't be indexed.
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 am concerned about doing a product animated presentation with SVG. The planed animation is a little too complex to be achieved with regular DOM manipulation (non SVG) and of course canvas is not an alternative since the content has to be indexed by Search engines. The animation is already mocked up and follows a typographic style.
That concern comes from the fact that I don't know if dynamic generated and injected text inside SVG will be indexed by search engines with the same richness other DOM elements will, or if it will be indexed at all!?
Would be good to know if somebody here already managed this situation, in practice, and if the indexing happened as expected (although any good and well documented hypothesis could help). In negative case, alternative solutions are welcome too.
No - it won't be in your page when it is crawled. If you want content to be indexed, serve it up straight from the server.
In all my websites XHTML source code, navigation and breadcrumbs appear below the content of the page yet visually they appear above. I am doing this as believe that in such way search engines find content more relevant.
In all the HTML5 examples I've seen, the order is classical:
header, body section, footer.
From SEO point of view, by working on HTML5 page, is it better to use classical tags order or the one I used till now in XHTML?
Unfortunately, this is more or less outdated advice.
Both Google and Bing have for many years now had the ability to render the DOM of the page and determine the actual layout of the page regardless of how the code is structured.
The old theory behind this technique was that search engines would only index the first 100kb or so of a page and typically that could be taken up by templated boilerplate code in some instances. This isn't a restriction that really exists anymore and to be honest if your pages are reaching that kind of filesize you probably have other things that you want to consider.
I think it is better when the content with keywords appear earlier in the source code. For the general link structure it doesn't matter where main navigation links are placed.
But maybe search engines can weight structure different when using standard semantic ids like navigation, breadcrumbs, content and footer? In this case the position would be equal. Isn't the semantic thing one of the big advantages of HTML 5?!