HTML5 Doctor » Browser Compatibility

YouTube and Vimeo support HTML5 Video

Richard Clark — Sat, 23 Jan 2010 16:08:28 +0000

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 element.

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 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!

Share and Save:

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

Your Questions Answered #4

Richard Clark — Wed, 09 Dec 2009 08:52:14 +0000

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., or
) 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 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., . All XML attributes must have explicit quoted values, so in XML this would be written as .

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., . Is this valid in HTML5? Would this be the valid version for XHTML5:

?

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
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

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

is not appropriate for footnotes, and you could argue that post details are footnotes. Also, the

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

or a

for the post details, but I’m not clear on what you mean by “controls”.

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

September 23rd, 2009

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

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

element (if absent, it will read “Details”).

The control that the user agent should render (when fully supporting the

element) is a small triangular button to the left that, when clicked, toggles the visibility of the element’s contents.

If the

element should be open by default, it should have its open attribute set.

I would use

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

, 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 :

September 23rd, 2009

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



Gig: Hixie and the Pixies, Jan 1st 2010, Royal Albert Hall
Published Sept 21, 2009

With Lachy on kazoo, Henri on Sousaphone, Pilgers on the triangle, and Hixie conducting

I feel a post about the 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.

Share and Save:

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

Your Questions Answered #3

Richard Clark — Thu, 22 Oct 2009 13:52:44 +0000

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:

Continue working as you are with new HTML5 elements and change them as the spec becomes more defined
Use HTML4, with HTML5 class names (as you suggested)
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.

Share and Save:

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

Absent Elements and Validation

Richard Clark — Tue, 25 Aug 2009 14:30:14 +0000

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 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 HTML 5. 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:

Which elements or attributes are deprecated?
Do I use any of those elements or attributes on my site?
How much do I need to worry about validation?
What effect will this have for backwards compatibility?
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 HTML 5 specification are: basefont, big, center, font, s, strike, tt, u, 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 HTML 5 differences from HTML 5.

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 HTML 5. Alternatively you may decide to remove them and use CSS for presentation in the case of or

Guy told use that he works for a large university. The site uses a large number of 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: HTML 5:

Change the doctype to HTML 5 and leave the elements in. (Bear in mind the HTML won't validate)
Change the doctype to HTML 5 edit the elements to become elements as advised by the specification
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 HTML 5 doctype.

However, those pages don't validate because they use the and

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 HTML 5 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 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 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 HTML 5. 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 HTML 5 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 HTML 5, 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 HTML 5's new elements, javascript API's or offline storage is a whole different subject.

Share and Save:

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

Legend not such a legend anymore

Remy Sharp — Fri, 31 Jul 2009 12:00:26 +0000

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:


  Terms & Conditions
  You agree to xyz, etc.

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.

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:

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:

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.

Share and Save:

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

Native Audio in the browser

Mark Boas — Wed, 29 Jul 2009 15:00:29 +0000

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 HTML 5

One of the most exciting and long-awaited features in HTML 5 the element, enabling native audio playback within the browser. We can take advantage of this for browsers that support it — such as Safari 4, Firefox 3.5 and Chrome 3 — while falling back on Flash or other plugins for other browsers.

According to spec

Currently, the HTML 5 spec defines five attributes for the element:

src — a valid URL specifying the content source
autobuffer — a boolean specifying whether the file is to be buffered in advance
autoplay — a boolean specifying whether the file should play as soon as it can
loop — a boolean specifying whether the file should be repeatedly played.
controls — a boolean specifying whether the browser should display its default media controls

Note that these are the same attributes defined for the element.

Examples

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

(This example will work for Firefox 3.5 and Chrome 3. You’ll need to replace the Ogg file with an MP3 to get it working in Safari 4.)

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 browsers
Browser	Ogg Vorbis	MP3	WAV
FireFox 3.5	✓		✓
Safari 4		✓	✓
Chrome 3 (beta)	✓	✓
Opera 10 (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

Note that Opera 10 does not support the HTML element, but it does support the Audio() API in a basic and unique manner: from the above list, it only supports the play() method.

Safari 4, Firefox 3.5, and Chrome 3 beta support both and Audio(). Internet Explorer 8 has no native audio support whatsoever.

Use the Source

The best way to coerce browsers into playing audio (or video, for that matter) is to use the 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:

One caveat, though: you need to be careful about the order of the elements. Because of a bug in Firefox, if you list the MP3 first (which Firefox doesn’t support), it will silently fail and refuse to render that particular element. The trick is to list the Ogg Vorbis file first and the other formats after. Webkit (Safari and Chrome) handle unsupported formats just fine.

Opera is another kettle of fish altogether, which we’ll need to solve using JavaScript.

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 HTML 5 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 HTML 5 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!

Our job was made more difficult by the lack of available information:

Firefox 3.5 — quite a detailed document
Safari 4 — technically complete, but lacks explanations and examples
Opera 10 — only a short note
Chrome 3 — a wiki

Since the HTML 5 standard is still a work in progress, several aspects of the element vary from browser to browser. For example, there seems to be no way to determine the load progress of an audio file. Although Safari 4 can determine how much of an audio file has downloaded, Firefox 3.5 does not yet implement the buffered DOM attribute. (It is, however, included as part of the Firefox’s documentation, so we presume it will be implemented.)

Firefox 3.5 does appear to enable “seeking” of the file, allowing you to start the download from any point in the media. Other browsers, such as Safari 4, grab the file from the beginning and only allow seeking within the part already downloaded (or wait until the particular part being seeked to has been downloaded).

Although these inconsistencies aren’t showstoppers, in order to compete effectively with plugin-based solutions, we believe any HTML 5 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 HTML 5 audio checker.

Using JavaScript, you can check for audio tag support:

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

or check for the Audio() object:

try {
  // The 'src' parameter is mandatory in Opera 10, so have used an empty string "".
  // Otherwise, an exception is thrown.
  myAudioObj = new Audio(""); 

  audioObjSupport = !!(myAudioObj.canPlayType);
  basicAudioSupport = !!(!audioObjSupport ? myAudioObj.play : false);
} catch (e) {
  audioObjSupport = false;
  basicAudioSupport = false;
}

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
if (myAudio.canPlayType) {

  // Currently canPlayType(type) returns: "no", "maybe" or "probably"
  canPlayOgg = ("no" != myAudio.canPlayType("audio/ogg")) && ("" != myAudio.canPlayType("audio/ogg"));
  canPlayMp3 = ("no" != myAudio.canPlayType("audio/mpeg")) && ("" != myAudio.canPlayType("audio/mpeg"));
}

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.

So, to create a solution that takes full advantage of HTML 5 audio, you’ll typically need to:

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

The Road Ahead

Although HTML 5 audio is a relatively immature part of the standard, if recent trends continue and users upgrade to the latest versions of Safari and Firefox, browser support will likely rise above the 25% mark in the very near future. 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.

And when you consider that mobile and other lower-spec devices — like Apple’s iPod and iPhone (Safari), Nintendo’s Wii (Opera), and Google Android-powered devices (Chrome) — are choosing to support HTML 5 audio rather than Flash, you begin to paint a picture of how important native audio support will soon become.

HTML5 Reset Stylesheet

Richard Clark — Mon, 27 Jul 2009 14:00:42 +0000

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.4.1 
2010-03-01
Author: Richard Clark - http://richclarkdesign.com
*/

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,canvas,details,figcaption,figure,
footer,header,hgroup,menu,nav,section,summary { 
    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;
    border:0;
    font-size:100%;
    vertical-align:baseline;
    background:transparent;
}

ins {
    background-color:#ff9;
    color:#000;
    text-decoration:none;
}

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 #000;
    cursor:help;
}

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

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 ,

and . (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 , 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 and . 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 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 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?

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 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, 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!

HTML 5 Reset Stylesheet
Related Posts:

Share and Save:

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

2022, or when will HTML 5 be ready?

Remy Sharp — Tue, 21 Jul 2009 14:19:00 +0000

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 inappropriate 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.

Share and Save:

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

“Block-level” links in HTML5

Bruce Lawson — Mon, 13 Jul 2009 12:00:06 +0000

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:


Bruce Lawson voted sexiest man on Earth
A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.
Read more

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:



Bruce Lawson voted sexiest man on Earth
A congress representing all the planet's women unanimously voted Bruce Lawson as sexiest man alive.
Read more

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.)

Share and Save:

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

HTML 5 + XML = XHTML 5

Bruce Lawson — Thu, 02 Jul 2009 14:20:41 +0000

(Also available in Spanish Traducción de “HTML 5 + XML = XHTML 5″ and Portuguese.)

I like the xhtml syntax. It’s how I learned. I’m used to lowercase code, quoted attributes and trailing slashes on elements like br and img. They make me feel nice and comfy, like a cup of Ovaltine and The Evil Dead on the telly.

But you might not. You might want SHOUTY UPPERCASE tags, no trailing slashes and attribute minimisation. And, in HTML 5, you can choose.

Thanks to the “pave the cowpaths” principle, it’s up to you. As you like it. What you will. Whatever you want, whatever you like.

But let no-one tell you that HTML 5 kills XML—meet XHTML 5.

XHTML 5 is the XML serialisation of HTML 5 and, as you’d imagine, it has all the stricter parsing rules that you’d expect (and are used to if, like me, you grew up with XHTML DOCTYPES). It must be served with an XML MIME type, such as application/xml or application/xhtml+xml (so no rendering in Internet Explorer for the moment) and will throw a wobbly at the slightest well-formedness violation. (See Serving XHTML with the Right MIME Type for more information.)

Usual XML rules apply: no document.writes allowed, no DOCTYPE required, some syntax and script differences to trip up the unwary and you can use namespaces.

The main differences are summarised on the official WHATWG wiki Differences Between HTML and XHTML. It’s also possible to write polyglot documents that can be processed as either by browsers, depending on the MIME type used.

Magne emailed the Doctor to ask “Is it OK to use HTML5 tags in a page with the XHTML 1.1 doctype? Which one should I use, as in, which one is the recommendation now?”

If you want to use the new features, you need to use HTML 5 DOCTYPE or XHTML 5. Given that Internet Explorer cannot process XML, for pragmatic reasons the Doctor advises HTML 5.

Share and Save:

HTML 5 + XML = XHTML 5 originally appeared on HTML5 Doctor on July 2, 2009.

HTML5 Doctor » Browser Compatibility

YouTube and Vimeo support HTML5 Video

Will it work cross browser?

The elephant in the room

Why use Ogg?

Where does that leave us?

Related Posts:

Your Questions Answered #4

Older browsers and XHTML

ARIA

Attribute Minification

Offline storage

Nav Title (in the document outline)

or something similar with the words “main navigation” good enough? If so, is hiding it with display: none okay? Thanks, DRoss

Your Questions Answered #3

Multiple use of tags

HTML5 + Javascript Client Web App

MIME or DOCTYPE, which one prevails

Outline Algorithm

HTML5 and xmlns

Developing to a changing spec

HTML5 and Browser Compatibility

Related Posts:

Absent Elements and Validation

The Question

The Doctors Response

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?

Summary

Related Posts:

Legend not such a legend anymore

Overview of the details element

The issues

Legend treatment

Internet Explorer

Opera

Safari

Firefox

Impact on other elements

Conclusion

Related Posts:

Native Audio in the browser

Enter HTML 5

According to spec

Examples

Use the Source

Cross-Browser Implementation

JavaScript solutions

The Road Ahead

Further reading:

Related Posts:

HTML5 Reset Stylesheet

The code

So what’s new?

The basics

Using attribute selectors

What’s that bit about mark?

Where are all those application elements?

Go grab it

Related Posts:

2022, or when will HTML 5 be ready?

What is the important HTML 5 date?

Related Posts:

“Block-level” links in HTML5

Bruce Lawson voted sexiest man on Earth

Bruce Lawson voted sexiest man on Earth

Shiny, but not new

Related Posts:

HTML 5 + XML = XHTML 5

Related Posts:

or something similar with the words “main navigation” good enough? If so, is hiding it with `display: none` okay?

Thanks,

DRoss