I've admired Sam Ruby's desire to use inline SVG for his blog - I think his clip art adds visual appeal to his site. I wish I had Sam's artistic sensibilities/patience (or that slipping into a scotch-induced trance would help). But artistic ability aside, I have been struggling with inline SVG as a concept since then. I thought I'd outline the advantages and disadvantages to inline SVG as I see them.
Advantages for Inline SVG
- other web authors can copy your SVG code and paste into their web pages without having to save off a separate SVG file and deploy it on their server
- web authors cannot hot-link to your SVG images
- reduces number of document fetches the browser has to make with the web server for that page (but see Disadvantages #1 and #2 below)
- simplified DOM access if you're into scripting
Disadvantages for Inline SVG
- Your web pages are larger in total size
- SVG images cannot be cached by the browser
- Browser plugins cannot handle inline SVG (prevents some viewers from seeing it)
- Only officially supported in XHTML, which IE does not support
- No fallback mechanism available for inline images
Based on Sam's recent discussions in the HTML WG, I'm guessing Sam values Advantage #1 above others.
Of course it's going to depend on what you're trying to do. For clip art like Sam's site, it's not necessary that every reader see the images or that fallback content is required - so there's a political message there (start using a cool web browser like Firefox or Opera instead of that clunky blue 'E'). On the other hand, every time Sam writes an entry dealing with WHATWG, he has to go to one of his previous WHATWG entries, search through the source, copy & paste the SVG code - it just seems like an inconvenience for him when a HTML:object to some usefully named file would do the same thing and produce a smaller page.
By the way, I recently noticed that Sam came up with a funny image for Java (note there are two hyperlinks in that image). The strange part is that he made it a separate 2k file but then also embedded the whole file inline.
“he has to go to one of his previous WHATWG entries, search through the source, copy & paste the SVG code”
Or just use a cool web browser – e.g. with Opera you can simply put the code to a note and with one right click and navigating to this note you did the job
Actually, although it’s not a benefit of inline SVG as such, I can see it being useful if you need to store images in a database for dynamic retrieval – much easier to store and retrieve as text than to write a separate script to retrieve the binary data and force it into the correct MIME type.
johnny – as you say, this may be a benefit of SVG, but it doesn’t say anything about inline or referenced.
False.
The svg:desc element provides a somewhat functional fallback mechanism.
Jacques,
I was primarily talking about fallback content that would automatically be displayed in browsers (without forcing the users to have to look at the source).
Jeff
@Jacques: In thinking about this this morning, the <desc> or <title> element contents would be displayed (as HTML text) in browsers that don’t support inline SVG – however unfortunately also the same thing applies with <text> elements, offering a potentially confusing experience…