Wednesday, July 25, 2007

SVG as image format

There are two common methods for adding SVG to a page - inline, via <svg>, and externally, via <object>.

The <object> element is bad. It's not semantic - it may as well be called <other> or <miscellaneous>. Although useful in the short term for displaying SVG, I would hope that this use will diminish.

The inline <svg> element is also bad, for the same reason - it's not semantic. It's the equivalent of having a <jpg> element, rather than using <img> - it's named after the format, rather than the purpose.

From the semantic perspective, there are three potential uses of SVG.

  • Foreground images: use <img src="x.svg"> to point to an SVG file
  • Background images: use CSS "background-image" to point to an SVG file
  • Inline with connected DOM: use <iframe> to point to an SVG file.

These are much better because they re-use existing semantic elements.

Unlike foregrounds or inline images, backgrounds should not enable any user interaction - events (e.g. mousedown), hyperlinks, pseudo-classes (e.g. :hover), etc. Some people say javascript should be turned off - this might be a rough and ready first implementation, but some javascript might be appropriate (e.g. random placement of shapes, or animation), so long as the "no user interaction" rule is followed.

The other advantage of <img> and CSS background-image over <svg> is that you don't need to use XHTML. Standard HTML gets round a whole series of issues with mime types, browser control, and backwards compatibility.

Advantages of SVG as image format

SVG images fill a lot of gaps with HTML styling:

  • rounded rectangles, circles, and any polygon
  • fancy borders (arcs, swirls, etc)
  • opacity, color gradients and filters
  • shape hyperlinks and :hover, rather than pixel maps
  • interaction via the DOM (for foreground images)
  • scaling of background images multiple backgrounds (in one SVG)
  • background text (e.g. graffitti, murals, etc)
  • intricate website 'themes' to each page

The possibilities for graphical designers are huge.

Browser support

I'm very pleased to see that the next version of Opera will support SVG images via <img> and background-image. Unfortunately, it's not on the schedule for either Firefox 3 or Safari 3, although it's an aspiration for both teams.

There are four possible methods of using SVG in a webpage - <svg>, <object>, <img>, and CSS backgrounds.

The SVG implementation status for Firefox and Safari is marked at around 55%. Personally, while they only support two of these four methods, I'd hold them at half this - 22%.

3 comments:

Jeff Schiller said...

Jay, would you call the <html> element bad? The reason I ask is it's roughly the same thing as calling the <svg> element "bad" because of lack of semantics: Both elements are the root XML node of a _document_ format. The key here is that SVG is a document format, just like HTML. The difference is that SVG focusing on documents of a graphical nature.

The "semantics" of the SVG element/document are obtained by looking at the XML attributes and elements it contains - just like HTML.

I also think that <object> has a practical use here: to provide fallback content. Neither iframe nor embed nor image allow that...

I also fail to see why Opera supporting SVG as an <img> is so great - as mentioned before you can do everything with SVG using <object> (AND provide fallback content for browsers that don't support SVG) - so why do you prefer <img> exactly?

Thanks,

Chris Jay said...

Hey Jeff - thanks for the comment.

I was referring to <svg> elements inside an HTML document, where semantics apply, not as the root node of a SVG document (where it's fine).

Your practical point about <object> is true. Ideally, <img> should work that way too...

I would prefer to use <img src="x.svg"/> or CSS background-image:url('x.svg') for SVG inside an HTML document, because they're the closest semantically for what it's for. And from a practical standpoint, it fixes a few limitations with background images.

Tommy said...

I concur.

The Scalable Vector Graphics "should" be supported by graphic producing elements in HTML/CSS.