Two new HTML elements have been defined for that purpose: <audio> and <video>, based on the generic media element type.

Media elements use a common set of attributes:

• src: defines the source of the media to render,
• autoplay: boolean to activate|prevent immediate playback,
• loop: boolean to activate|prevent automatic looping on content,
• controls: boolean to display|hide browser playback user interface.

<video> and <audio> elements can contain elements to be displayed to the user in older browsers that do not support these new elements.

Below is an example of how to use the <audio> element:

<audio src="audio.ogv" controls width="100" height="50">
    <a href="audio.ogv">Listen</a>
</audio>

Alternatively to the src attribute, the content to be rendered can be specified using one or more <source> elements, each of them describing a specific media resource.

Each <source> can be identified by its src and type attributes, optionally complemented by a codecs attribute:

<audio controls width="100" height="50">
     <source src="audio.ogg" type="audio/ogg; codecs=vorbis">
    <source src="audio.spx" type="audio/ogg; codecs=speex">
    <source src="audio.oga" type="audio/ogg; codecs=flac">
</audio>

The <video> element has an optional poster attribute that can be used to define an image to be displayed before the video is played:

<video src="oggy.ogv" poster="oggy.jpg" />

These new media elements also support a set of handy javascript method, properties and events, to allow the fine-grained control of the rendered UI.

• play()
• pause()
• currentTime: current playback time,
• duration: overall duration of the media,
• playbackRate: playback speed (can be negative !),
• onplay(): content has just start playing,
• onpause(): content playback has just been paused,
• onerror(): an error occurred,
• …

<script>
function playVideo(url){
     var video = document.getElementById("video");
     video.setAttribute("src",url);
}
</script>
<video id="videoPlayer" controls=false/>
<p>
     <button type="button"
             onclick="video.playbackRate = -2;">
         Rew
     </button>
     <button type="button"
             onclick="video.play();">
         Play
     </button>
     <button type="button"
             onclick="video.pause();">
         Pause
     </button>
     <button type="button"
                 onclick="video.playbackRate = 2;">
         FF
     </button>
</p>

• <section>: represents a document or application section (a content column for instance),
• <article>: represents an independent piece of content inside a document/section (a blog entry for instance),
• <aside>: represents a piece of content not directly related to the displayed content (typically a sidebar),
• <header>: represents a document header,
• <footer>: represents a document footer,
• <nav>: represents a block of navigation links (typically a blog navigation bar),
• <dialog>: can be used to render a chat session, using complementary <dt> (talker) and <dd> (quote) tags,
• <figure>: can be used to provide textual information about an embedded content,
• <address>: represents a document/section contact block,

Its XML counterpart is XHTML 1.1, successor of XHTML 1.0 defined in 2000 and revised in 2002 by the W3C.

The newest XHTML 2.0 was at first meant to replace both, but the fact that it was not compatible with XHTML 1.1 raised quite a controversy.

This, added to the fact that some major internet companies and non-profit organizations wanted to expand the typical browser experience to include other internet usages like messaging and media playback led to the creation of the Web Hypertext Application Technology Working Group (WHATWG), that released in 2005 the first version of the HTML 5 specification.

The W3C started in 2007 a new HTML working group that took the WHATWG HTML 5 specification as a basis, leading to the publication of the first HTML 5 draft in 2008.

The W3C HTML 5 working group is led by Ian Hickson from Google, Inc (WHATWG HTML 5 specification editor, CSS 2.1 co-editor, Acid2 and Acid3 developer) and David Hyatt from Apple, Inc (Safari/Webkit project leader, Firefox co-founder).

The HTML 5 specification defines both HTML and XHTML document types.

The W3C maintains a list of differences between HTML 5 and HTML 4.

I will try to explain these differences in separate posts:

• <section> and associated new block-level elements,
• <audio> & <video> elements,
• offline web applications,
• … TBC …

This is a shame because it may lead people to use a deprecated HTML syntax for presenting content instead of using CSS. This will lead to future incompatibilities and extensive use of the “Quirks mode”.

I will summarize below the main differences between the strict and transitional models. Then, the reader may be able to figure out whether he can safely switch to (X)HTML strict or not.

Elements only allowed in transitional (X)HTML

The list below has been compiled using this full XHTML doctypes element comparison

• applet,
• basefont,
• center,
• dir,
• font,
• frame,
• frameset,
• iframe,
• isindex,
• menu,
• noframes,
• s,
• strike,
• u,

Today, only the iframe element is still used widespread, despite the fact that it can be replaced by object.

Attributes only allowed in transitional (X)HTML

The list below has been compiled using this full XHTML doctypes element attributes comparison

• align in anything but tables-related elements,
• alink,
• background,
• bgcolor,
• border,
• color,
• compact,
• dir,
• face,
• frameborder,
• height,
• hspace,
• ismap,
• height,
• lang,
• link,
• noshade,
• nowrap,
• object,
• size,
• start,
• target on anchors a,
• text,
• type,
• version,
• vlink,
• vspace,
• width.

As you can see, most of these attributes can easily be replaced by CSS rules. The only one that is still used widespread is a.target. In my humble opinion, this is not a problem, because you should not decide to open a link in a new window on behalf of the user. Anyway, if you really want to do that, you can still use javascript.

Document structure constraints in strict (X)HTML

The body, blockquote and form must only contain block-lebel elements like div or span.

To be short, HTML documents must start with a DOCTYPE declaration that is used by the browser to choose the appropriate rendering. It allows in particular to distinguish between real HTML documents and XHTML documents served as text/html to non-XHTML browsers (though required by the XHTML specification, the DOCTYPE declaration is actually redundant with the namepace declaration if the document is served as application/xhtml+xml).

The current HTML specification is HTML 4.01 (1999). It defines three document types:

• HTML 4.01 strict, that relies entirely on CSS for presentation
• HTML 4.01 transitional, that still allows deprecated presentational markup
• HTML 4.01 frameset, that must only be used to declare framesets

In a first attempt to replace HTML 4.01, the W3C has defined XHTML 1.0 (2000-2002), that redefines HTML 4.01 using a strict XML syntax. Unsurprisingly, XHTML 1.0 also defines three document types:

• XHTML 1.0 strict, that is exactly HTML 4.01 strict with closing tags,
• XHTML 1.0 transitional, that is exactly HTML 4.01 transitional with closing tags,
• XHTML 1.0 frameset, that must only be used to declare framesets.

In a later standardization effort, the W3C produced XHTML 1.1 (WIP), that doesn’t add much, but defines only a strict DOCTYPE.

To summarize, when developing a new page, the first thing you need to decide is if you go for HTML or XHTML. My recommendation is to always choose HTML unless you really need XHTML (for instance because you want to add inline SVG).

Then, in both cases, unless you really need to use the deprecated HTML syntax, then use the strict DOCTYPE.

HTML

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Please note that according to the W3C XHTML guidelines, the XML declaration (<?xml version="1.0" encoding="UTF-8"?>) should be omitted, as it triggers quirks mode in older versions of Internet Explorer. This is only a problem if you need to specify a different character encoding than UTF-8 (the default).

As a web developer willing to use inline SVG, your best bet is thus to provide fallback mechanisms to display IE visitors at least a degraded version of what you’re trying to express/demonstrate, and teach them what they’re missing by sticking with evil IE.

Luckily, IE will simply ignore any markup it does’nt know, so you usually don’t need to bother masking or removing the SVG markup when serving pages to your IE visitors.

This is however not true if you insert plain text if your SVG … Let’s take an example.

When you insert the following SVG in your page:

<svg xmlns="http://www.w3.org/2000/svg"
       version="1.1" wiewBox="0 0 200 100">
   <text x="0" y="0"
         font-family="Verdana"
	 font-size="55" fill="blue" >
        Hello, out there
   </text>
</svg>

IE will ignore all SVG markup and formatting, and actually display the plain text with the current style:

Hello, out there

Now, what happens when you insert HTML markup inside your SVG using the foreignObject tag ?

<svg xmlns="http://www.w3.org/2000/svg"
       version="1.1" wiewBox="0 0 200 100">
   <foreignObject width="200" height="100">
      <span style="color:blue;">
        Hello, out there
      </span>
   </foreignObject>
</svg>

Well, IE ignores all SVG and displays only the HTML markup embedded in the foreignObject tag:

Hello, out there

Based on this behavior, the guys at Sheperd interactive have imagined a very elegant inline SVG fallback mechanism that uses SVG conditional processing.

In a nutshell, the actual SVG and the IE fallback are embedded in an SVG switch:

• SVG aware browsers will recognize the conditional directive, and render the first alternative they understand (the actual SVG), ignoring the other (the IE fallback)
• IE will silently ignore all SVG markup (including the conditional directive), and go straight to the fallback written in HTML.

In the example, below, SVG-aware browsers will display a red circle, and IE a simple text.

<svg xmlns="http://www.w3.org/2000/svg"
        version="1.1" wiewBox="0 0 200 100">
  <switch>
     <circle cx="150px" cy="100px" r="50px"
               fill="#ff0000" stroke="#000000"
               stroke-width="5px"/>
     <foreignObject width="200" height="100">
        <span style="color:red;">
          This is not a red circle
        </span>
     </foreignObject>
   </switch>
</svg>

See the actual rendering below:

What does SVG add to the web developer toolkit ?

Well, as its names indicates, SVG first provides a simple syntax to draw shapes that scale: it is thus particularly handy to draw screen layouts and buttons. I see some people starting to get interested …

But wait: SVG also includes a wide range of gradient, opacity and geometric transformations that can be applied not only to native SVG shapes, but also to images. This give you access to many fancy effects very hard to achieve with HTML alone, like for instance image reflection or fading.

Want more ? Check this out: SVG markup can be modified dynamically using javascript, allowing you to actually animate it. Who said cover-flow at the back of the class ?

Animation through javascript sucks on low-end devices ? Well, SVG also includes native animation capabilities (unfortunately only supported today by Opera).

Fair enough, but the whole web is built on top of HTML, and switching to full SVG is definitely an option.

Well, the cherry on the cake is that you don’t have to: SVG can be inserted inline into XHTML. How powerful that is ?

You will find detailed information on why and how it works on the SVG wiki. A method to have inline SVG supported by IE using the Adobe SVG viewer is also provided.

Here is an overview of what you need to do.

• First, you need to use XHTML, because plain old HTML doesn’t support being extended by another markup language, and your SVG markup will be ignored by the browsers.
• Second, you need to make sure that the SVG-aware browsers know this is XHTML, by delivering your content to them as application/xhtml+xml. You probably nevertheless still want to deliver your content to IE as text/html, so what you need is conditional mime-types based on the Accept header of the user agent.
  • it can be done at the HTTP server level. See example below for apache (example taken from the SVG wiki):

    AddType text/html .xhtml
    RewriteEngine on
    RewriteBase /
    RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
    RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
    RewriteCond %{REQUEST_URI} \.xhtml$
    RewriteCond %{THE_REQUEST} HTTP/1\.1
    RewriteRule .* - [T=application/xhtml+xml]
    

  • If you don’t have access to your web server configuration, you can still:
    • modify headers on the fly. See an example for PHP below:

      if(preg_match("|application/xhtml\+xml|i",$_SERVER["HTTP_ACCEPT"]){
        header("Content-Type: application/xhtml+xml");
      }
      

    • or insert meta tags in the HTML head to specify the proper mime-type. See another example for PHP:

      if(preg_match("|application/xhtml\+xml|i",$_SERVER["HTTP_ACCEPT"]){
        echo "<meta http-equiv='Content-Type' content='application/xhtml+xml' />" ;
      }
      

    • If you use WordPress, the simpliest way is to use the Content-Negotiation plugin
• Third, put your SVG under an SVG tag

<div id="myDIV">
    <svg xmlns="http://www.w3.org/2000/svg" version="1.1"
	 xmlns:xlink="http://www.w3.org/1999/xlink"
	 viewBox="0 0 400 50"
	 id="myDIVBG">
	    <defs>
	      <linearGradient id="myGrad">
		<stop style="stop-color:#ff5b06;"
                        offset="0" />
		<stop style="stop-color:#ffb11a;"
                        offset="1" />
	      </linearGradient>
	    </defs>
	    <rect style="fill:url(#myGrad);"
	       width="400" height="50"
               x="0" y="0" rx="10" ry="10" />
    </svg>
    HTML Text with SVG background
</div>

• Fourth, style your SVG with CSS

<style type="text/css">
#myDIV {
    position:relative;
    width:400px;
    height:50px;
}
#myDIV svg {
    position:absolute;
}
#myDIV svg:hover rect {
    fill: red !important;
}
#myDIV span {
    position:absolute;
    top:15px;
    left:40px;
    font-size: 16px;
    font-weight: bold;
}
</style>

The result should look like this:

Please note in particular how the CSS styling allows the SVG to be perfectly integrated in the page:

• the absolute positioning of the svg root element allows the next-coming HTML span to appear on top of the SVG background
• the :hover behaviour allows a dynamic update of the SVG rect element fill attribute when the element is moused over

You will find more examples below:

• A form with an SVG background at Mozilla’s,
• A simple proof of concept