HTML5 Doctor » Browser Compatibility http://html5doctor.com helping you implement HTML5 today Wed, 16 May 2012 11:31:21 +0000 en hourly 1 http://wordpress.org/?v= Using Modernizr to detect HTML5 features and provide fallbacks http://html5doctor.com/using-modernizr-to-detect-html5-features-and-provide-fallbacks/ http://html5doctor.com/using-modernizr-to-detect-html5-features-and-provide-fallbacks/#comments Tue, 27 Mar 2012 13:30:04 +0000 Tom Leadbetter http://html5doctor.com/?p=4371 Modernizr is a JavaScript library that detects which HTML5 and CSS3 features your visitor's browser supports. In detecting feature support, it allows developers to test for some of the new technologies and then provide fallbacks for browsers that do not support them. This is called feature detection and is much more efficient than browser sniffing. In this article we'll look at how to use Modernizr for feature detection.

]]> Modernizr logo

Modernizr is a JavaScript library that detects which HTML5 and CSS3 features your visitor’s browser supports. In detecting feature support, it allows developers to test for some of the new technologies and then provide fallbacks for browsers that do not support them. This is called feature detection and is much more efficient than browser sniffing.

Modernizr is very useful for detecting CSS3 support, but this article will focus on HTML5. The principles are essentially the same, though.

It’s important to note that Modernizr doesn’t “fill in the gaps” (i.e., polyfill) for you. It only detects whether something is supported. But you can use Modernizr as part of the polyfilling process.

Versions of IE8 and below do not recognise new-in-HTML5 elements by default, so you have to fix this with some JavaScript. You could possibly create each of these yourself with the below code, or you might use the HTML5 Shiv by @rem, which includes all the new elements.

Modernizr does all this for you, so you don’t need include the Shiv.

Getting Started

First, you need an HTML document:

<!DOCTYPE html>
<html class="no-js" lang="en">
<head>
  <meta charset="utf-8">
  <title>Hello Modernizr</title>
  <script src="modernizr.js"></script>
</head>
<body>
</body>
</html>

You can see in the code above that you need a modernizr.js file. You have to build and download this yourself by choosing the features you want to detect. Do this by choosing the ‘Production’ option in Figure 1 and then ticking the necessary options in Figure 2. This helps keep the file size down by not detecting everything Modernizr is capable of. There is a development version (see Figure 1) that you can link to whilst developing your site, but before you put the site live, you should build the production file you need.

Modernizr download options

Figure 1: Modernizr download options
Modernizr build options

Figure 2: Modernizr configuration & build options

Also notice the second line of the HTML above: there is a no-js class on the <html> element. Modernizr first removes this and replaces it with a js class, which could be useful in your CSS. Along with the js class, it adds classes for all the features the browser supports and for the features it does not support, pre-fixing those with no-.

Here are two examples, one from Chrome 16 and one from IE9:

<html class="js flexbox canvas canvastext webgl no-touch geolocation postmessage websqldatabase indexeddb hashchange history draganddrop websockets rgba hsla multiplebgs backgroundsize borderimage borderradius boxshadow textshadow opacity cssanimations csscolumns cssgradients cssreflections csstransforms csstransforms3d csstransitions fontface generatedcontent video audio localstorage sessionstorage webworkers applicationcache svg inlinesvg smil svgclippaths">
Figure 3: Modernizr’s feature detection in Chrome 16
<html class="js no-flexbox canvas canvastext no-webgl no-touch geolocation postmessage no-websqldatabase no-indexeddb hashchange no-history draganddrop no-websockets rgba hsla multiplebgs backgroundsize no-borderimage borderradius boxshadow no-textshadow opacity no-cssanimations no-csscolumns no-cssgradients no-cssreflections csstransforms no-csstransforms3d no-csstransitions fontface generatedcontent video audio localstorage sessionstorage no-webworkers no-applicationcache svg inlinesvg smil svgclippaths">
Figure 4: Modernizr’s feature detection in IE9

Do Some Detecting

Modernizr creates a global Modernizr JavaScript object, which allows us to query different properties of that object to perform feature detection by calling Modernizr.<featurename>. So to test for canvas support, you would write the following:

<script>
  if (Modernizr.canvas) {
    alert("This browser supports HTML5 canvas!");
  }
</script>

So try this page in a modern browser and there will be a nice message for you.

Because you’re all good developers and write unobtrusive, progressive JavaScript so that everyone can use your site, you also want to check if canvas is not supported. You have a couple of options here. You could use the above if statement along with an else statement, like so:

<script>
  if (Modernizr.canvas) {
    alert("This browser supports HTML5 canvas!");
  } else {
    alert("no canvas :(");
  }
</script>

Or if you want to test purely for no canvas support, you can negate the condition like this:

<script>
  if (!Modernizr.canvas) {
    alert("No canvas here");
  }
</script>

Feature Detection and Polyfilling with YepNope

In the examples above, you’ve seen the simplest way to detect a browser feature. What if you wanted to detect a feature and use a polyfill to make the browser perform better? You can do this with YepNope.

YepNope is a conditional loader, which means it will only load the scripts that are needed by the browser. And it’s built into Modernizr, so you don’t have to worry about downloading and linking to another JavaScript file.

So how do you use it?

Using canvas as an example again, you’ll generally want a fallback for non-supporting IE8 and below. The usual way of doing this would be to link to a JavaScript polyfill, such as FlashCanvas in your HTML:

<script src="http://flashcanvas.net/bin/flashcanvas.js"></script>

The problem with this approach is that all browsers will download this script. That’s unnecessary and should be avoided where possible. You could arguably wrap the <script> element in conditional comments, but if you can keep the files out of the markup altogether, then you should. You can do this using Modernizr.load(). Modernizr has YepNope built into it, so you can easily test for a feature and then supply a polyfill.

So let’s take a look.

You should note that .load() is not included in the development file by default. You need to include it and build it yourself.

The basic use of the .load() function allows you to test for a feature and ask whether it’s true (yep) or false (nope). In this example, Modernizr tests for canvas support, and if the feature doesn’t exist, then it loads FlashCanvas:

Modernizr.load({
  test: Modernizr.canvas,
  nope: 'http://flashcanvas.net/bin/flashcanvas.js'
});

So open up IE8, take a look at the network tab (Figure 5) in the developer tools. With the above code, you’ll see that it downloaded and initialised flashcanvas.js. Pretty nifty, yes?

Figure 5: FlashCanvas resources loaded in IE8

Here’s a more practical example that detects the support of <input type="date">. If it isn’t supported, it loads in two jQuery files and a CSS file to generate a styled date picker:

<script src="modernizr.js"></script>
<script>Modernizr.load({
  test: Modernizr.inputtypes.date,
  nope: ['http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js', 'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.7/jquery-ui.min.js', 'jquery-ui.css'],
  complete: function () {
    $('input[type=date]').datepicker({
      dateFormat: 'yy-mm-dd'
    });
  }
});
</script>

This test looks for <input type="date"> support. When it fails, it loads in the two external jQuery JavaScript files and a local CSS file. (Our tests suggest that the CSS file needs to be local.) Once it’s done that (i.e., on complete), it then calls the plugin for each <input type="date"> in the DOM. In most browsers, the jQuery will be loaded (Figure 6), but in Opera, the files aren’t loaded because it has a native calendar control (Figure 7):

jQuery date picker widget

Figure 6: jQuery date picker widget in Firefox
Opera date picker widget

Figure 7: Native date picker widget in Opera

The two figures below show the difference in which resources the browsers downloads:

Resources loaded in Firefox

Figure 8: Date picker resources loaded in Firefox
Resources loaded in Opera

Figure 9: Date picker resources loaded in Opera

Notice how the two jQuery JavaScript files are loaded twice. That’s a YepNope behaviour, first loading the resource and then executing it. So don’t worry, that’s normal.

You can do much more with YepNope. Here’s an example taken from the YepNope web site of all the possible properties, all of which are optional:

yepnope([{
    test : /* boolean(ish) - Something truthy that you want to test */,
    yep : /* array (of strings) | string - The things to load if test is true */,
    nope : /* array (of strings) | string - The things to load if test is false */,
    both : /* array (of strings) | string - Load everytime (sugar) */,
    load : /* array (of strings) | string - Load everytime (sugar) */,
    callback : /* function ( testResult, key ) | object { key : fn } */,
    complete : /* function */ }, /* ... */ ]);

Conclusion

Modernizr is a powerful feature detection library. It allows you to check whether a browser supports various features and, depending on what you want to achieve, lets you use a polyfill. This article looked at how to generate a Modernizr JavaScript file and examined two different ways of using Modernizr: directly using the Modernizr object (Modernizr.<featurename>) and then using the built-in YepNope.

So, what do you think? Let us know in the comments below!

Using Modernizr to detect HTML5 features and provide fallbacks originally appeared on HTML5 Doctor on March 27, 2012.

]]> http://html5doctor.com/using-modernizr-to-detect-html5-features-and-provide-fallbacks/feed/ 13 YouTube and Vimeo support HTML5 Video http://html5doctor.com/youtube-and-vimeo-support-html5-video/ http://html5doctor.com/youtube-and-vimeo-support-html5-video/#comments Sat, 23 Jan 2010 16:08:28 +0000 Richard Clark http://html5doctor.com/?p=1315 XHTML2 shaped rock for the past week or so you'll know that both YouTube and Vimeo have announced plans to support the HTML5 video element.]]> Unless you’ve been hiding under an XHTML2 shaped rock for the past week or so, you’ll know that both YouTube and Vimeo have announced plans to support the HTML5 video element. Two blog posts published last week announced that the two major players in online video are experimenting with the HTML5 <video> element.

YouTube and Vimeo Logos

Will it work cross browser?

The videos will work natively in Safari and Chrome (well, YouTube would certainly have to, wouldn’t it?). They’ll also work in IE if you have ChromeFrame installed (which we all know is cheating). If you’re using a browser that doesn’t support HTML5 video it will default back to the Flash method they currently employ.

Both YouTube and Vimeo use the H.264 codec to encode the videos — and that’s where things start to get complicated.

Since no official codec is defined in the spec because browser manufacturers have chosen to use different codecs to render HTML5 video. Opera and Mozilla use the Ogg Theora codec (more on that later), while Apple and Google use H.264. Who knows which side of the fence Microsoft will come down on, but I feel duty bound to mention that the licensors of the H.264 codec include both Microsoft and Apple.

The elephant in the room

There’s one major problem here: Ogg Theora, the open source video codec supported by both Firefox and Opera, is not supported on either site. It’s a shame these browsers aren’t supported, especially since Firefox 3.6 was released last week and announced support for full-screen video in its native video player.

Why use Ogg?

As previously stated, Ogg is an open source codec, meaning it’s free to use and implement. By contrast, support for native H.264 decoding in a browser costs approximately $5 million per year. (See summary of AVC/H.264 license terms [PDF].) It also seems that people creating H.264 content will be liable for royalties starting in 2011.

Far be it from me to get into the ins and outs of the debate over which codec to use, but it seems that open source would be the better way to go. Silivia Pfeiffer (a contractor for Mozilla) claims that serving as Ogg Theora will reach more people than serving as H264.

Google, on the other hand, which owns YouTube has said that Theora is not a good enough codec, claiming “If [youtube] were to switch to theora and maintain even a semblance of the current youtube quality it would take up most available bandwidth across the Internet”, a claim hotly (and convincingly) contested in Greg Maxwell’s YouTube / Ogg/Theora comparison.

YouTube and Vimeo seem to have discounted Ogg. I’d love to find out if there are other plans to add support for Firefox and Opera.

Where does that leave us?

Ignoring the whole video codec debate, it leaves us in some ways back where we started — dealing with proprietary software or complicated licensing to create online content rather than using technologies that will allow us to have a truly open web.

With Apple, Google, Mozilla, and Opera not likely to budge on their respective codec choices for HTML5 video, we can only hope that the developers at market-leading sites like YouTube and Vimeo can implement cross-browser interoperable video just like Kroc Camen’s Video for Everybody. Judging by the aforementioned blog posts, both sites have more plans in the pipeline, which is encouraging.

The codec battles are only beginning, and we’re waiting to see which direction one big gun will point. Last year, Google (which owns YouTube) announced that is paying $104million for a company called On2 Technologies, “a leading creator of high-quality video compression technology” and which made the original VP3 codec which is the basis for Ogg Theora.

What are their plans? To release a “better” Theora-like codec into the community? We can only speculate.

Back to today. Although not perfect, these sites’ support for the <video> element is still a massive leap forward for HTML5. Who knows — if more large sites continue to adopt HTML5, maybe it’ll be ready in 2010 rather than 2022!

YouTube and Vimeo support HTML5 Video originally appeared on HTML5 Doctor on January 23, 2010.

]]> http://html5doctor.com/youtube-and-vimeo-support-html5-video/feed/ 25 Your Questions Answered #4 http://html5doctor.com/your-questions-answered-4/ http://html5doctor.com/your-questions-answered-4/#comments Wed, 09 Dec 2009 08:52:14 +0000 Richard Clark http://html5doctor.com/?p=1242 Illustration of a doctor treating a patient Here we go with another post rounding up your HTML5 questions and sharing the answers with the world. We cover a wide range of topics this time, inlcluding ARIA, storage, offline capabilities, and document outlines, so read on to find the answers.

We also want to know what areas of HTML5 you’d like us to cover in future articles, so let us know!

Older browsers and XHTML

Brett Prichard asked:

If I were to use one of the new tags in HTML5, (i.e., <video> or <header>) what would happen when the page is rendered by an older browser?

The other question I have is will there be an XHTML equivalent? XHTML 2.0 breaks off compatibility with HTMLs 1-4, but will it be compatible with HTML5? I prefer to code in XHTML.

Thank you for reading.

To answer your first question: nothing special. The content nested within the element is displayed. (In the case of video, the fallback content is shown.)

Regarding your second question, I wrote about the XHTML serialisation of HTML5 a while ago.

— Thanks, Bruce

ARIA

Joseph Chapman asked:

My colleagues and I wish to switch our doctype to the streamlined <!doctype html> and implement several things we learnt from Jeremy Keith last Wednesday, primarily ARIA.

We know that support is good as long as we add an extra DTD, but we can’t find the appropriate doctype declaration to stick on the end of ...html> Any ideas? We are really keen to kick this off and use a new piece of technology that will help springboard our site to a new level of accessibility.

Any answers appreciated.

Thanks for your help.

It’s okay to add ARIA to HTML5 now without using a different doctype. I suggest you give this part of the spec a read.

I believe a task force has been created to more closely align ARIA to HTML5. We plan to cover ARIA more in a future post.

Hope this helps

— Rich

Attribute Minification

Nick Leon asked:

Hey there HTML5Doctor,

I consider myself a strong POSH developer. One of the requirements for valid XHTML is that “attribute minimization” is not allowed. HTML permits “attribute minimization”, where boolean attributes can have their value omitted entirely, e.g., <option selected>. All XML attributes must have explicit quoted values, so in XML this would be written as <option selected="selected">.

I was wondering where HTML5 stands with attribute minimization. I noticed in some of your example code, you provided the minimized form of the attribute, e.g., <audio src="elvis.ogg" controls autobuffer></audio>. Is this valid in HTML5? Would this be the valid version for XHTML5:

<audio src="elvis.ogg" controls="1" autobuffer="0"></audio>?

Those are both valid HTML5 structures (however, controls=”1″ isn’t legal; you need to say controls=”controls”).

In HTML5, you can format attributes as you please. In XHTML5 (the XML serialisation), you need to obey the XML rules.

— Cheers, Bruce

Offline storage

Kevin Searle asked:

I’m having a hard time wrapping my head around the offline storage capabilities of the HTML 5 spec. Can you consider an “HTML 5 Offline Storage 101″ article?

Just to clarify, do you mean “storage” or “offline”? They’re two very different things.

Storage relates to variables, like cookie jars but a lot bigger.

Offline applications are about detecting connectivity and possibly running your app without a connection to the Web.

We (i.e., Remy) will be writing about both of these topics, but it’s useful to know which is more in demand than the other.

In the meantime, feel free to check out the demos I’ve written at HTML5 Demos (covering offline, storage, and web databases).

— Remy

Nav Title (in the document outline)

D Ross asked:

Working on my new site and checked it with the outliner. I’m getting an “untitled section” showing up because I don’t have a headline inside my “nav” element.

Is this correct? Do I really need to title my main nav?

If so, is adding an <h5> or something similar with the words “main navigation” good enough? If so, is hiding it with display: none okay?

Thanks,

DRoss

Yes, “untitled section” is fine. I know it’s been suggested to the developer of the outliner that it should say “navigation” or something similar, but I’m not sure when or whether that will happen. (You’ll see the same thing with <aside> too if there’s no heading nested directly beneath the element).

Thanks,

— Rich

The details element

Bart asked:

Hello Doctors!

I’d like to ask you a little help with understanding the “details” element.

As the W3 spec says: “The details element represents a disclosure widget from which the user can obtain additional information or controls”.

I’m not sure if I get it right, but I think I can use this element to put details about a post (such as date and time) and controls, including “answer”, “save” and “repost”.

Please tell me if I’m wrong.

Regards, Bart

PS. I love the HTML5doctor blog, it’s so important to explain how to use HTML5. Keep up the great work!

This question triggered a flurry of responses from several of us doctors, so we’ve added them all here for you.

Answer 1

The spec says <details> is not appropriate for footnotes, and you could argue that post details are footnotes. Also, the <details> element has the option to show or hide its content, which suggests to me that it’s not appropriate for the post details.

You could possibly use a <section> or a <footer> for the post details, but I’m not clear on what you mean by “controls”.

For the date/time, you can use the <time> element:

<time class="published updated" datetime="2009-09-23">September 23rd, 2009</time>

Other doctors might have other opinions, but I hope this helps.

— Tom

Answer 2

Just to follow up on Tom’s reply: the user viewing your content can control whether or not they see the details.

The <details> element is an interactive element that is collapsed by default, so that only the heading is visible. The heading should be marked up in a <dt> element (if absent, it will read “Details”).

The control that the user agent should render (when fully supporting the <details> element) is a small triangular button to the left that, when clicked, toggles the visibility of the element’s contents.

If the <details> element should be open by default, it should have its open attribute set.

I would use <details> for any content that still allows the surrounding content to make sense while not necessarily needing to be seen. So in your example, I would put the metadata in the <details>, but not the “user controls” to reply, save, etc., since the user should always be able to see that they can perform these actions.

While the browser vendors haven’t implemented the interactive aspect of details, I, for one, will be emulating this using JavaScript.

I hope that helps (too!).

— Remy

Answer 3

You can also use pubdate as an attribute of <time>:

<time pubdate datetime="2009-09-23">September 23rd, 2009</time>

pubdate is useful when you have two different times in the post. For example, for a future event:

<article>
<header>
<h1>Gig: Hixie and the Pixies, <time datetime="2010-01-01">Jan 1st 2010</time>, Royal Albert Hall</h1>
<p>Published <time datetime="2009-09-21" pubdate>Sept 21, 2009</time></p>
</header>
<p>With Lachy on kazoo, Henri on Sousaphone, Pilgers on the triangle, and Hixie conducting</p>
</article>

I feel a post about the <time> element coming on…

— Bruce

More to come

That wraps up this round of questions! We’d like to know what areas of HTML5 you’d like us to cover in future articles, so leave a comment below or send us an e-mail.

Your Questions Answered #4 originally appeared on HTML5 Doctor on December 9, 2009.

]]> http://html5doctor.com/your-questions-answered-4/feed/ 5 Your Questions Answered #3 http://html5doctor.com/your-questions-answered-3/ http://html5doctor.com/your-questions-answered-3/#comments Thu, 22 Oct 2009 13:52:44 +0000 Richard Clark http://html5doctor.com/?p=1061 We’re back with our (semi) regular round up of answering readers HTML5 related questions. Right, let’s not mess about any longer and dive straight in with the questions.

Multiple use of tags

Daniel Davis asked:

Dear Doctor,

Just a quick confirmation please.

Am I right in thinking that nav, like header and footer, can be used more than once in a single page? For example, surrounding a menu at the top of the page and surrounding next/previous buttons at the bottom.
Come to think of it, is it fair to say that all tags except html, head and body can be used more than once?
Thanks in advance, doctor.

I’ll be back soon about my dodgy knee.

You’re correct all the elements you mention can be used more than once a page. If you see this article about the header and this about the footer – they show that you can use them multiple times on a page. Also you don’t really need html, head or body tags, as all browsers will assume them anyway but it’s also safe to leave them included.

— Hope that clears things up Rich and Bruce

HTML5 + Javascript Client Web App

Girish asked:

Is it possible to create a complete client side application using HTML 5 (it will embed chat clients, stock ticker) + JavaScript, and then bundle is with underlining Firefox 3.5 engine, so that user can install it as a desktop app on Linux, and then it runs in its own window using firefox 3.5 engine. The app will store everything in local storage – like url, usernames etc, and will not interact with any local server.

It would pure HTML5 + JavaScript based client web app which would be packaged, and can be installed or launched from startup scripts.

Or instead of using firefox 3.5 engine, we can use Mozilla Prism to convert it to web app, and then bundle it, is it possible?

Technically it should be possible. Certainly the HTML5 offline applications API (via the manifest) gives you all that ability to create a client side app and it run locally without a web connection.

However, the browser is the problem. Prism might be a good way to deploy this as a standalone app, but I don’t know if Prism is running the latest Gecko engine (or whether that comes with the JS engine, etc) – and even if it does – Firefox 3.5 currently has a pretty severe bug with the offline applications: it doesn’t work!

I have logged the bug with Mozilla and I know they’re working (in fact, I believe they’ve fixed it and are now testing).

The alternative is to use Fluid (a Webkit based app) – but again, that’s only if they have updated to the latest Webkit and thus including the offline applications API (that said, quickly looking at the Fluid site, their in-progress version may have the latest Webkit).

Regarding launch from start up scripts – you could achieve this though the custom scheme handlers (but this is just Firefox IIRC): http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#custom-handlers

Equally, there may be an API that you could exploit via the standalone browser, either Prism or Fluid.

— Good luck! Remy

MIME or DOCTYPE, which one prevails

Pedro Estébanez asked:

Hello doctor,

I have found this site a very good resource for web developers and I thank you for your effort.

Now, my question:

There is a lot of discussion about hot to tell the browser we are using HTML5 or XHTML5 by setting the Content-Type HTTP header. But then I don’t know the true role the DOCTYPE plays (apart from keeping quirks mode from being activated and validation).

For example, if I compose my documents as XHTML with an according DOCTYPE and my server serves them as text/html, why XML mode is not triggered in the browser?

Thanks in advance.

Did you see this article on the site from Bruce? HTML5, XML and XHTML5 and this one from Remy HTML5 Boilerplates.

Also see this (linked in Bruce’s article) for some advice on using the right mime type. http://www.webstandards.org/learn/articles/askw3c/sep2003/.

— Cheers Rich

Outline Algorithm

Mike Taylor asked:

In Section 4.4.11.1 of the current HTML5 spec, the outline algorithm is described–yet it’s not super clear in what ways this is useful to users or developers. It would be great if some more light could be shed on the topic!

Thanks for the awesome blog, btw.

The outliner basically allows you to easily see the heading structure of a site. The outline can then figure out from the heading structure where in the outline it should sit, should you want to only parse a section of the code into another site or page for example. (I realise this isn’t totally clear). Also check out the HTML5 Outliner for checking your work.

Bruce covered it a little bit in his section article – “With very few exceptions, section should not be used if there is no natural heading for it. Check your work in the HTML 5 outiner tool. If you see any instances of “untitled section” that corresponds to a section, you’re probably doing it wrong. (It’s fine for a nav or aside element to be untitled, however).”

We’ll try and cover it in more detail in a future post but I hope this helps for now, Rich.

HTML5 and xmlns

Ad Taylor asked:

I hope this isn’t a stupid question BUT …

If I am using the html5 DOCTYPE and I am still using xhtml syntax do I need to define the xmlns in the html tag (i.e. xmlns=”http://www.w3.org/1999/xhtml”)?

Thank you for taking the time to do this.

We said, Not a stupid question, but a simple answer: No!

— Ta Bruce (HTML5 Shrink)

Developing to a changing spec

Sam Rayner asked:

I read the Super Friends Guide to HTML5 Hiccups – http://www.zeldman.com/superfriends/guide/ and it’s worried me a little.

I’ve recently been developing personal projects using HTML5 as I find I learn best ‘on the job’ and wish to become familiar with the new spec by putting it in to practice. However, it sounds like I’ve misinterpreted bits and often used new elements such as footer in the way the Super Friends describe rather than in line with the spec.

I really want to continue enjoying the benefits of HTML5 in my own non-critical web work but it seems I run the risk of having to return to it all at a later date and amend stuff due to changes in the spec.

What do you think the best course of action is? Continue with 5 but keep going back and fixing old projects? – Could become a real hassle.

Continue with 5 and leave non-visual discrepancies as they are (the code may be slightly off but it’s styled fine)? – Goes against all of my natural instincts to do things right.

Return to 4 and use class names as apposed to the new elements for the time being?

I realise this is the risk I take developing with a developing spec but I’m worried if I wait until everything is set in stone I’ll still be using HTML4 years from now!

Thanks a lot,

I understand your concerns with the spec changing from day to day. It’s hard to keep up with (there’s 6 of us and that’s tough enough).

Although I’m sure you’re aware in footers case, its content model has now been changed to allow it to act more like header.

I think essentially you have three choices for your development or a combination of the below currently:

  1. Continue working as you are with new HTML5 elements and change them as the spec becomes more defined
  2. Use HTML4, with HTML5 class names (as you suggested)
  3. Use only the simplified doctype and those elements that will only be benificial in the future or add progressive enchancement (e.g. inline elements such as time.)

Its going to be a while until we can use HTML5 in development projects but in my opinion there isn’t any reason to not use it on personal projects now. You have to judge it on a case by case basis, but whichever parts you do you will be futureproofed to some extent.

— Cheers Rich

HTML5 and Browser Compatibility

A lot of people ask this type of question regularly so here’s a few links that we think are useful.

That about wraps up this round of questions, we’ll be publishing more soon, but in the meantime don’t be afraid to keep asking the doctor about HTML5.

Your Questions Answered #3 originally appeared on HTML5 Doctor on October 22, 2009.

]]> http://html5doctor.com/your-questions-answered-3/feed/ 15 Absent Elements and Validation http://html5doctor.com/absent-elements-and-validation/ http://html5doctor.com/absent-elements-and-validation/#comments Tue, 25 Aug 2009 14:30:14 +0000 Richard Clark http://html5doctor.com/?p=777 HTML or XHTML pages to the HTML 5 doctype will have on those elements that are deprecated current draft.]]> We received the below question from Guy Carberry who was wondering what effect changing the doctype on your HTML or XHTML pages to the HTML 5 doctype will have on those elements that are deprecated current draft.

The Question

There are several aspects to consider from this question so lets start by taking a look at Guys question in full.

Jeremy Keith says that we can change the Doctype declaration on XHTML 1.0 syntax pages to <!DOCTYPE html> and it will immediately become HTML 5.

I'm a bit confused about what that means for the Absent and changed elements and attributes info detailed here: http://www.w3.org/TR/html5-diff/#absent-elements

"Some attributes from HTML 4 are no longer allowed in HTML5. If they need to have any impact on user agents for compatibility reasons it is defined how they should work in those scenarios."

So if this is that case, how can you switch the doctype declarations and all be fine?

Thanks for your help,

Guy.

The Doctors Response

In answering the question we will need to break the question down into the following:

  1. Which elements or attributes are deprecated?
  2. Do I use any of those elements or attributes on my site?
  3. How much do I need to worry about validation?
  4. What effect will this have for backwards compatibility?
  5. Can my content be accessed in all my target browsers and user agents?

Lets consider each of these in some more detail below.

1. Which elements or attributes are deprecated?

The elements deprecated (from HTML 4.01) from the HTML5 specification are: basefont, big, center, font, strike, tt, frame, frameset, noframes, acronym, applet, isindex, dir

You can find a list of those elements and attributes along with detailed reasons of why they've been removed by reading HTML5 differences from HTML5.

2. Do I use any of those elements or attributes on my site?

If your site uses any of the above named elements or attributes you may consider changing them to more semantic elements as introduced in HTML5. Alternatively you may decide to remove them and use CSS for presentation in the case of <font> or <center>.

Guy told use that he works for a large university. The site uses a large number of <acronym> tags which have been removed from HTML 5 as detailed above. To solve this issue for Guy, I feel he has three options if he wishes to make the site: HTML5:

  1. Change the doctype to HTML5 and leave the <acronym> elements in. (Bear in mind the HTML won't validate)
  2. Change the doctype to HTML5 edit the <acronym> elements to become <abbr> elements as advised by the specification
  3. Do nothing and leave the site as HTML 4.01 or XHTML

It's difficult to be able to advise Guy on which option he should choose without knowing the full extent of the effort involved to implement these solutions or knowing the sites goals and project teams views on validation. Speaking of validation, the whole area is a minefield and it's what we'll attempt to cover next.

3. How much do I need to worry about validation?

While validation is undoubtedly important for your markup and your CSS, in my opinion it isn't crucial to a site. Allow me to explain, we recently received a couple of emails pointing out that this site doesn't validate. While there were some errors that have now been corrected, a primary reason why is the use of ARIA roles in the markup. These attributes currently aren't allowed in the current specification, however there is work underway to make this happen.

To illustrate this point let's look at Google, the search giant. If you look at the source on Google's search pages you'll see they use the HTML5 doctype.

<!DOCTYPE html>

However, those pages don't validate because they use the <font> and <center> elements amongst others things that we already know have been removed from the specification. Does this mean that users stop visiting Google? No.

Remember too that the specification is yet to be finalised and may still be changed (thus breaking you're perfectly valid docments), in partnership with this changes to the specification may not immediately take be implemented in the validators. We also need to bear in mind that HTML5 takes a "pave the cowpaths" approach to development, meaning that the Hixie, et al will look at what authors already do and improve upon it.

4. What effect will this have for backwards compatibility?

Leading on from the point about Google as mentioned previously we know Googles site not validating doesn't matter but is it still backwards compatible? Yes. As far as we know, all the browsers support the <font> tag. It's the validators that don't. If you want to use an antiquated element you can do, the browser will still handle it - it just won't validate.

In terms of backwards compatibility there is no reason why you couldn't start using new HTML 5 elements in your HTML 4.01 or XHTML 1.x documents, it could even be described as progressive enhancement. For example, why not include the <video> element? It won't validate but maybe that doesn't matter? The browser will still be able to render video, hence "paving the cowpaths". Having said that if you're going to the effort of including new elements why not go the whole hog and change the doctype too?

5. Can my content be accessed in all my target browsers and user agents?

Again to look at Google, it still renders in older browswers and devices but to all intents and purposes it's HTML5. Another aspect that the specification defines is that new features should work in or not break in older browsers.

Remy pointed out in a response to Guy that

Remember that the browser is still going to handle this, regardless of whether HTML5 supports this or not. Just like and XHTML document although doesn't validate with frames, it still renders fine and still supports frames.

So from that we can conclude that browsers will still render deprecated elements or practices.

Summary

To wrap up I think we can answer Guys question by saying yes, changing the doctype will make your site HTML5, but whether or not it validates is in essence an entirely personal or business decision. Whether this means you are making use of all the benefits of HTML5's new elements, javascript API's or offline storage is a whole different subject.

Absent Elements and Validation originally appeared on HTML5 Doctor on August 25, 2009.

]]> http://html5doctor.com/absent-elements-and-validation/feed/ 5 Legend not such a legend anymore http://html5doctor.com/legend-not-such-a-legend-anymore/ http://html5doctor.com/legend-not-such-a-legend-anymore/#comments Fri, 31 Jul 2009 12:00:26 +0000 Remy Sharp http://html5doctor.com/?p=646 Lately I decided I was going to recreate the interactive features of the details element using JavaScript (apparently the same day as fellow Brightonian Jeremy Keith).

However I ran in to some very serious issues with the tag, so serious, in it’s current state, it’s unusable.

Overview of the details element

The details element, by default, is a collapsed element whose summary, or label, is the first child legend (if no legend is used, the UA provides a default, such as “Details”), with a triangular button to indicate it’s current open state.

If you include the open attribute, then the element is open by default. In theory, you could attach a click event to the legend, and switch the open attribute.

The markup would roughly be this:

<details open="open">
  <legend>Terms & Conditions</legend>
  <p>You agree to xyz, etc.</p>
</details>

Here’s the details test page I was working from: HTML 5 details test

The issues

The biggest problem, and the show stopper for me, is that the browser’s treatment of the legend element completely breaks this markup pattern – this is true for all the major browsers: Opera, Safari, Firefox and IE (tested in all the latest and some older browsers). I’ll go in these issues in detail in a moment.

Other problems include:

  • Styling the legend element is exceptionally difficult, particularly positioning
  • Using the WHATWG guidelines to styling the details element prove both difficult to interpret and difficult to implement.
  • When using CSS to style the open state of the details element using: details[open] { height: auto; }, meant that once I changed the open state using JavaScript, it wouldn’t trigger the browser to redraw (as it would if I had added a class). I’ve run in to this before, CSS 2.1 is styling source, not the DOM.

Legend treatment

Surprisingly Firefox is the worst one out in these issues, the rest of the browsers have fairly same treatment of the issue. In the screenshots, I’ve included a fieldset and nested legend for reference.

Internet Explorer

IE7 & IE8 closes the legend element it encounters when it’s not inside a fieldset element and move it’s contents out to an adjacent text node.

What’s also strange, is that looking at the DOM it also creates another empty(?) closed legend element after that text node. It doesn’t have any effect, but just looked odd:

IE's details element treatment

Opera

Opera (9 & 10b) is very similar to IE in it’s treatment of the legend in the details element, except it doesn’t create the second closing legend node. It just closes the legend, and creates the adjacent text node.

Safari

Safari simply strips the legend all together out of the DOM. So much so, that if you open the web inspector, then the error console, you’ll see it warning out that it’s encountered an illegal element, ignoring it, then encountering the closing tag, so it ignores that too. You’re left with just the text node.

Firefox

The best for last. Firefox goes one step beyond the other browsers. It assumes you’ve forgotten to include the fieldset element. So when it hits the legend element, Firefox inserts an opening fieldset up until it finds (I believe) the closing fieldset element, which obviously it doesn’t so the result is the rest of the DOM, after the first illegally placed legend ends up eaten by fieldset element, which leaves my DOM in a mess:

Firefox details treatment

Impact on other elements

details isn’t the only element that reuses the legend element for labelling, the figure element also is supposed to support the legend element. The result is obviously going to be the same.

Conclusion

We can’t style the legend element when the text is being thrown out by all the browsers, and Firefox’s DOM mangling is just too painful to look at.

This basically means that we can’t, in any reasonable amount of time, use the legend element inside both the details and figure element in the spec’s current state.

For me, I’ll be using an alternative element, probably just a p element styled to look like a legend, but that’s really not the point. Ideas anyone?

It turns out we weren’t the only ones looking at this and Ian Hickson has responded on the issue:

My plan here is to continue to wait for a while longer to see if the parsing issues can get ironed out (the HTML5 parser in Gecko for instance solves this problem for Firefox). If we really can’t get past this, we’ll have to introduce a new element, but I’m trying to avoid going there.

It’s fine to think that Gecko will update, but it’s IE that I’m worried about, they won’t turn out their render engine, and the result is we’ll have to avoid using the legend in any element other than fieldset.

Legend not such a legend anymore originally appeared on HTML5 Doctor on July 31, 2009.

]]> http://html5doctor.com/legend-not-such-a-legend-anymore/feed/ 19 Native Audio in the browser http://html5doctor.com/native-audio-in-the-browser/ http://html5doctor.com/native-audio-in-the-browser/#comments Wed, 29 Jul 2009 15:00:29 +0000 Mark Boas http://html5doctor.com/?p=497 Until recently, the ability to play any type of audio within a browser involved using Adobe Flash or other browser plugins. Although Adobe's Flash player is unquestionably the most ubiquitous of these, most developers and designers would agree that it's better not to rely on a plugin at all.

Enter HTML5 <audio>

One of the most exciting and long-awaited features in HTML5 the <audio> element, enabling native audio playback within the browser. We can take advantage of this now as nearly all of the major browsers support it — currently Firefox, Chrome, Safari and Opera, but they are soon to be joined by Internet Explorer 9 which is currently in beta. For browsers that don't support audio natively, we can easily fallback to Flash.

According to spec

Currently, the HTML5 spec defines five attributes for the <audio> element:

  1. src — a valid <abbr>URL</abbr> specifying the content source
  2. autoplay — a boolean specifying whether the file should play as soon as it can
  3. loop — a boolean specifying whether the file should be repeatedly played.
  4. controls — a boolean specifying whether the browser should display its default media controls
  5. preload — none / metadata / auto — where 'metadata' means preload just the metadata and 'auto' leaves the browser to decide whether to preload the whole file.

Note preload supercedes autobuffer in the latest HTML5 spec. Previously autobuffer took a boolean value specifying whether the file is to be buffered in advance. Currently, browsers are making the transition from autobuffer to preload so we suggest that you use both attributes for the time being.

Incidentally these are the same attributes defined for the <video> element.

Examples

Let's take a couple of these attributes and create a simple example that will play an audio file:

<audio src="elvis.ogg" controls preload="auto" autobuffer></audio>

(This example will work for the latest versions of Firefox, Chrome and Opera. You'll need to replace the Ogg file with an MP3 to get it working in Safari.)

Of course, the spec is not finalised, and there isn't yet a consensus on which codecs to support. This table details the codecs supported by today's browsers:

Codec support in modern desktop browsers
Browser Ogg Vorbis MP3 WAV
FireFox 3.6+ ✓ ✓
Safari 5+ ✓ ✓
Chrome 6 ✓ ✓
Opera 10.5+ ✓ ✓
Internet Explorer 9 (beta) ✓ ✓

To create our own controls, we can use the API methods defined by the spec:

  • play() — plays the audio
  • pause() — pauses the audio
  • canPlayType() — interrogates the browser to establish whether the given mime type can be played
  • buffered() — attribute that specifies the start and end time of the buffered part of the file

Use the Source

The best way to coerce browsers into playing audio (or video, for that matter) is to use the <source> element. The browser will try to load the first audio source, and if it fails or isn't supported, it will move on to the next audio source. In addition, we can embed a Flash player if all else fails:

<audio controls preload="auto" autobuffer> 
  <source src="elvis.mp3" />
  <source src="elvis.ogg" />
  <!-- now include flash fall back -->
</audio>

One caveat, though: you may need to be careful about the order of the <source> elements. At the time of going to press issues have been reported with Mobile Safari and older versions of Firefox.

Cross-Browser Implementation

When we created jPlayer, an audio player plugin for jQuery, we were attempting to address some of the limitations of the current crop of Flash-based audio players. Many relied on Flash to implement the player's graphical interface, effectively isolating the player from the rest of the web design process.

The original jPlayer relied on Flash to play the actual audio while allowing the look and feel to be styled via HTML and CSS. With growing support for HTML5 in modern browsers, we were inspired to break our Flash dependency and use native audio when it was supported.

The most significant issue is the cross-browser implementation, where lack of a common supported audio format among browsers causes complications. If developers want to take full advantage of all browsers that support HTML5 audio, they'll need to create both MP3 and Ogg (and in Opera's case, WAV) versions of the audio file they want to stream!

Since the HTML5 standard is still a work in progress, several aspects of the <audio> element vary from browser to browser. For example, there seems to be no way to determine the load progress of an audio file in all browsers as this relies on buffered DOM attribute being implemented. Chrome has implemented buffered, in Safari it's there but seems to behave slightly differently, current versions of Opera and Firefox however don't support it (although Firefox 4 beta does).

Although these inconsistencies aren't showstoppers, in order to compete effectively with plugin-based solutions, we believe any HTML5 audio implementation should be consistent across all browsers and match current implementations feature for feature.

JavaScript solutions

If we intend to take advantage of each browser's audio capabilities, we need to create different solutions for different browsers. We could use browser sniffing, but considering the rapidly changing landscape, it's better to check what capabilities a particular browser supports and adapt accordingly.

To demonstrate this "feature sniffing", we've created a rough and ready HTML5 audio checker.

Using JavaScript, you can check for audio tag support:

// returns a boolean
var audioTagSupport = !!(document.createElement('audio').canPlayType);

or check file type compatibility:

// Need to check the canPlayType first or an exception
    // will be thrown for those browsers that don't support it      

    var myAudio = document.createElement('audio'); 
    
    if (myAudio.canPlayType) {
      
       // Currently canPlayType(type) returns: "", "maybe" or "probably" 

       var canPlayMp3 = !!myAudio.canPlayType && "" != myAudio.canPlayType('audio/mpeg');
       var canPlayOgg = !!myAudio.canPlayType && "" != myAudio.canPlayType('audio/ogg; codecs="vorbis"');
    }

Note that to change the src attribute of an audio object or element, you'll need to recreate the object or element with the new value for its src attribute or alternatively change the src URL and then issue a myAudio.load() command.

So, to create a solution that takes full advantage of HTML5 audio, you'll typically need to:

  1. check for HTML5 audio support, and if not present, fall back on Flash,
  2. check the level of HTML5 audio support and adapt your code accordingly for each browser, and
  3. check what file types are supported and link to appropriate formats of the files.

The Road Ahead

Although HTML5 audio is a relatively immature part of the standard, if recent trends continue and users upgrade to the latest versions of Safari, Firefox, Chrome and Opera, browser support is likely above 30% today. This is a significant chunk of the browser market that will no longer need to rely on Adobe's Flash, Microsoft's Silverlight, or any other browser plugin for audio support. Add to this the fact that Internet Explorer 9 supports HTML5 audio and we could easily see the majority of installed browsers supporting it in the very near future.

And when you consider that mobile and other lower-spec devices such as tablets are choosing to support HTML5 audio, you begin to paint a picture of how important native audio support is becoming.

Further reading:

Native Audio in the browser originally appeared on HTML5 Doctor on July 29, 2009.

]]> http://html5doctor.com/native-audio-in-the-browser/feed/ 148 HTML5 Reset Stylesheet http://html5doctor.com/html-5-reset-stylesheet/ http://html5doctor.com/html-5-reset-stylesheet/#comments Mon, 27 Jul 2009 14:00:42 +0000 Richard Clark http://html5doctor.com/?p=622 HTML 5 so to give you all a helping hand and continue on from those basic building blocks that Remy talked about last week I've created a HTML 5 reset stylesheet for you to take away and use, edit, amend and update in your projects.]]> We’ve had a number of people ask about templates, boilerplates, and styling for HTML 5. Last week, Remy introduced some basic boilerplates for HTML 5, so to keep the momentum going, I’ve modified Eric Meyer’s CSS reset for you to use in your HTML 5 projects.

The code

Let’s start with the complete CSS stylesheet:

/* 
html5doctor.com Reset Stylesheet
v1.6.1
Last Updated: 2010-09-17
Author: Richard Clark - http://richclarkdesign.com 
Twitter: @rich_clark
*/

html, body, div, span, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
abbr, address, cite, code,
del, dfn, em, img, ins, kbd, q, samp,
small, strong, sub, sup, var,
b, i,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, figcaption, figure, 
footer, header, hgroup, menu, nav, section, summary,
time, mark, audio, video {
    margin:0;
    padding:0;
    border:0;
    outline:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

body {
    line-height:1;
}

article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section { 
    display:block;
}

nav ul {
    list-style:none;
}

blockquote, q {
    quotes:none;
}

blockquote:before, blockquote:after,
q:before, q:after {
    content:'';
    content:none;
}

a {
    margin:0;
    padding:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

/* change colours to suit your needs */
ins {
    background-color:#ff9;
    color:#000;
    text-decoration:none;
}

/* change colours to suit your needs */
mark {
    background-color:#ff9;
    color:#000; 
    font-style:italic;
    font-weight:bold;
}

del {
    text-decoration: line-through;
}

abbr[title], dfn[title] {
    border-bottom:1px dotted;
    cursor:help;
}

table {
    border-collapse:collapse;
    border-spacing:0;
}

/* change border colour to suit your needs */
hr {
    display:block;
    height:1px;
    border:0;   
    border-top:1px solid #cccccc;
    margin:1em 0;
    padding:0;
}

input, select {
    vertical-align:middle;
}

So what’s new?

Quite a bit! The next few sections explain what I changed and why I changed it.

The basics

I started by removing elements that have been deprecated from the HTML 5 specification, like <acronym>, <center> and <big>. (We’ll cover deprecated elements in more detail in another post). I also added new HTML 5 elements, like and, in order to remove any default padding, margin, and borders. I’ve also added an explicit display:block property for elements that are required to render as blocks.

I also removed the explicit unstyling of the :focus pseudo-class. There are two reasons for this. First, by declaring outline:0, you remove the focus identifier for keyboard users. Second, Eric released his stylesheet in good faith that people would explicitly style :focus, but they generally don’t, so it’s safer to leave the default :focus styles in place. (I also set defaults for <ins>, since I don’t think that got updated very often either.)

I’ve left the default list styles in place simply as a personal preference. I tend to add the list style back when using Eric’s reset anyway. I have, however, included nav ul {list-style:none;} to remove those pesky bullets from your navigation.

Using attribute selectors

You’ll notice that I’ve included attribute selectors for <abbr> and <dfn>. This way, the style will only appear if there is a title attribute on the element. This is primarily for accessibility. For example, we use <abbr> regularly on this site but don’t always include a title attribute. We think it’s safe to assume all of our readers (no matter what device they’re using) know what HTML stands for. We do still use the <abbr> element to make sure screen readers read the text as H-T-M-L rather than struggling to pronounce “HTML”.

What’s that bit about mark?

<mark> is a new element introduced in HTML 5 used to (you guessed it) mark text in a document. According to the spec: “The mark element represents a run of text in one document marked or highlighted for reference purposes, due to its relevance in another context.”. I anticipate it will be used for highlighting phrases in search results and other similar purposes. We’ll post more on <mark> soon.

Where are all those application elements?

Application elements is a term I’ve loosely used to describe elements like menu, etc. These elements are more likely found in web apps than web sites. I left these out since, at the time of writing, browsers implement barely any of what was “Web Applications 1.0″. Also, this stylesheet is intended primarily for authors serving their pages as text/html, not XML.

Go grab it

The stylesheet is released under a Creative Commons license in the public domain, so you can use it for both personal and commercial work. I thought I’d let Google take care of the hosting, so go grab it from Google Code and let us know about any improvements you make!

HTML5 Reset Stylesheet originally appeared on HTML5 Doctor on July 27, 2009.

]]> http://html5doctor.com/html-5-reset-stylesheet/feed/ 218 2022, or when will HTML 5 be ready? http://html5doctor.com/2022-or-when-will-html-5-be-ready/ http://html5doctor.com/2022-or-when-will-html-5-be-ready/#comments Tue, 21 Jul 2009 14:19:00 +0000 Remy Sharp http://html5doctor.com/?p=548 HTML 5 would be ready. That's wrong. HTML 5 is ready today.]]> Aside from being the year Queen Elizabeth II will celebrate her Platinum Jubilee, assuming she’s still kicking around, 2022 is the year that’s been inappropriately linked with HTML 5 in the minds of a lot of our community.

I understand why someone might think that, but it’s wrong. 2022 was misinterpreted as the year HTML 5 would be ready. That’s wrong. HTML 5 is ready today.

In an interview by Tech Republic, for a techie audience, Ian Hickson, the editor of the HTML 5 working draft, was asked to give a timeline of the HTML 5 recommendation.

One date should have come out of that interview, but another, much further away did instead: 2022 – the date of the final proposed recommendation, which actually translates to:

require at least two browsers to completely pass [HTML 5 test suites]

Let’s put this in context of another spec that has taken a very long time: CSS 2.1.

CSS 2.1 is CSS that I’m certain you’re familiar with. I’m certain you use it day to day without any thought as to whether it’s a completed spec.

It’s been in development for over 10 years, and it’s only just become a candidate recommendation (23rd April 2009).

That said, it doesn’t have two browsers completely supporting it. Only Internet Explorer 8 supports the full CSS 2.1 spec.

Did that stop you from using CSS 2.1? I suspect not. Will that stop us from using HTML 5? It certainly shouldn’t. HTML 5 is available and ready to be used today.

What is the important HTML 5 date?

October 2009.

This October is the last call for the HTML 5 working draft.

That means, that issues with the spec, enhancements, bugs, anything, it all needs to be in and submitted and written in to the spec for October this year (it can go through reiterations, the this is the main deadline).

The WHATWG is completely open for anyone to contribute their ideas and suggestions.

You can sign up to the mailing lists, look through the backlog of mailing list. You can communicate directly using IRC and there’s even a complete log of all the IRC history. All available from http://whatwg.org.

2022, or when will HTML 5 be ready? originally appeared on HTML5 Doctor on July 21, 2009.

]]> http://html5doctor.com/2022-or-when-will-html-5-be-ready/feed/ 38 “Block-level” links in HTML5 http://html5doctor.com/block-level-links-in-html-5/ http://html5doctor.com/block-level-links-in-html-5/#comments Mon, 13 Jul 2009 12:00:06 +0000 Bruce Lawson http://html5doctor.com/?p=455 HTML 5 is wrap links round "block-level" elements. Find out how this works, why it works with true-life sample code.]]> One new and exciting thing you can do in HTML 5 is wrap links round “block-level” elements.

Imagine you have a front page with lots of teasers for news articles, each of which leads to a page devoted to the full text of that article. Obviously, each story needs a heading and you’ll want an image too, and you’ll want them all clickable. In current mark-up you’ll probably have something like this:

<div class="story">
<h3><a href="story1.html">Bruce Lawson voted sexiest man on Earth</a></h3>
<p><a href="story1.html"><img src="bruce.jpg" alt="full story. " />A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</a></p>
<p><a href="story1.html">Read more</a></p>
</div>

Note that you have three identical links (or two if, like the BBC News site, you assume your readers don’t need a “read more” link).

In HTML 5, you code it like this:

<article>
<a href="story1.html">
<h3>Bruce Lawson voted sexiest man on Earth</h3>
<p><img src="bruce.jpg" alt="gorgeous lovebundle. ">A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.</p>
<p>Read more</p>
</a>
</article>

Now the single link surrounds the whole teaser, removing duplication and creating a much wider hit area to click.

Two points to make about accessibility in passing: firstly, you don’t need to worry that each "read more" goes to a different destination (see WCAG 2) because the whole story is the link, so the link text is unique. Secondly, note that I’ve changed the alternate text on the image, as in the first instance the image is a link so I described its destination, whereas the second is just a picture so I describe the image itself—”gorgeous lovebundle”—and thereby give more information to a screenreader user.

Shiny, but not new

What’s also very interesting about this technique is that actually this isn’t new: you can do it now. XHTML 2 had a similar mechanism, which allowed href on any element Eric Meyer called for this to be adopted in HTML 5 but, of course, this isn’t backwardly compatible. One of his other solutions to the same problem was changing the rules for a, and my test page shows that it works now in all the browsers.

That’s one of the interesting things about HTML 5—it documents existing browser behaviour. As the browsers already handle wrapping links around block-level elements, and there is an obvious use-case, there was no reason to artificially keep the structure as invalid.

(One irony: Eric Meyer’s original use-case was to link all cells in a table row. This doesn’t work in HTML 5; you need script for that.)

“Block-level” links in HTML5 originally appeared on HTML5 Doctor on July 13, 2009.

]]> http://html5doctor.com/block-level-links-in-html-5/feed/ 81