Same Markup: Using <canvas>, <audio>, and <video>

On this blog we’ve repeatedly discussed enabling the "Same Markup" for Internet Explorer 9. Part of making "Same Markup" a reality involves supporting the right features in IE9 to make the same HTML, JavaScript, and CSS "just work" the same way they do in other browsers. Part of how IE9 contributes to enabling the "Same Markup" is through support for the <canvas>, <audio>, and <video> elements from HTML5. These were introduced in the third platform preview and continue to be improved with each update.

In my first post on "Same Markup", I described the effort as an "n-way street". Each browser has a part to play by supporting the right features with the right behavior. Web developers also have a part to play in how they code for cross-browser differences where they unfortunately still exist. The most important part of working across browsers for web developers is to detect features, not browsers. So in this post I’ll outline how to use feature detection for <canvas>, <audio>, and <video>.

Detecting Support from HTML Markup

Unlike other features, support for <canvas>, <audio>, and <video> can be detected directly from HTML markup. This involves simply using the desired element, then placing fallback content inside of it intended for browsers that don’t have support for these elements. Browsers with support will hide this content from the user and display only the <canvas>, <audio>, or <video> element itself.

Of course, fallback content should also be useful. Exactly what qualifies as useful can vary depending on what you are trying to do. One approach is to point the user at a download for an upgrade, but in most cases it is a better experience for consumers to fall back to alternative approaches for delivering the content. For example, if you’re drawing something that doesn’t change much to a canvas, you may be able to fall back to an image that gets generated server-side. A better alternative could involve including a framework which implements canvas on top of existing web technologies or using a widely deployed plug-in.

The <audio> and <video> elements tend to have more options for fallback via plug-ins, whether through a media player or an app built on top of a widely deployed technology such as Flash or Silverlight. At the very least you can provide the user with a link to download the file so they can play it locally. The examples below provide a rough view of this type of fallback, though the <object> tag generally requires a number of varying parameters specific to the chosen plug-in.

Detecting Support from Script

In addition to HTML markup, support for <canvas>, <audio>, and <video> can also be detected from script. This detection can be performed many ways, but one of the simplest is to check for the existence of the appropriate interface object off of window.

An alternative approach for detecting <audio> and <video> involves checking for the existence of the canPlayType method on a dynamically created <audio> or <video> element. This is used by a number of frameworks and is generally preferred if you also intend to use the canPlayType method to test for supported codecs (which will be covered in a future post). If you simply need to test whether <audio> or <video> is supported, then I find the approach outlined above in examples 8 and 9 to be more obvious and equally as effective.

A similar alternative approach can be used for detecting <canvas> support. In this case, most frameworks have settled on checking for the existence of the getContext method. This makes sense for <canvas> given that this method is required in order to retrieve a context for rendering. In order to avoid false positives in a couple of mobile browsers, an additional check confirming that a context can actually be retrieved is needed as well (thanks to Paul Irish for pointing this out).

Next Steps

If you have previously used browser detection to decide whether to use <canvas>, <audio>, or <video>, now is the time to update to use feature detection instead. Also, make sure you have a DOCTYPE at the top of your page (e.g. <!DOCTYPE html>) so your content doesn’t render in Quirks Mode. In IE9, Quirks Mode is used for compatibility and consequently the <canvas>, <audio>, and <video> elements will not work there.

Stay tuned for future posts covering how to detect supported codecs and specify multiple sources using the <audio> and <video> elements.

Regarding the comment feeds, would it be possible when a blog entry stops accepting new comments, that the feed version of the comments includes a final entry stating that no more comments are being accepted, so people like me who use feed readers to keep up with the comments know when to unsubscribed? Thanks!

I was rather abruptly downvoted for suggesting a method similar to the script support detection method for <canvas> over on Stack Overflow a while ago – stackoverflow.com/…/2745459. My answer there was accepted, then unaccepted after a couple of downvotes, so reading this post made me feel a little better about it 🙂

IE9 PP has corrected unquoted attribute values, but tag names are still returned in uppercase… hence the fixTags function above… The W3 validators don't complain now with unquoted attribute values if the current documentMode==9 and you are using a code snippet retrieved from the innerHTML of a selected tag.

I expect that <canvas> and other new HTML 5 tags will return a different selection.type value once the iexplore.exe GUI is added and the context menu handlers for the new tags are updated. Currently abbr, acronym, center, cite, code, command, del, defn, canvas and svg tag names return a selection.type of 'None'

I would not be using document.write(el.outerHTML); or NewEl.innerHTML=el.outerHTML though, so the above workaround only applies to context menu utilities like Copy HTML that you may be using to inspect the contents of AJAX responses injecting markup into a page.

of coarse

You can always use the Script tab of the Developer Tools to copy the innerHTML of any tag, except injected markup from document.writes or innerHTML assignments.

@Rob – I think some of your post got chopped or you neglected to add the fixTags function. However I'm pretty sure @exy is talking about the existing innerHTML failures on Tables, Select and similar elements. There has been a lot of talk on the IE Blog about the new features in SVG and Canvas that IE is finally supporting but as you can see in @EricLaw[MSFT]'s reply he very specifically mentioned nothing about the innerHTML bugs. We're just not sure if that is because the IE Team has decided to drive us nuts by saving the fix announcement for the upcoming beta 2 Friday's from now or if the IE Team has decided to go Mum on the subject because they are embarrased that this fix will yet again not make it to a production build.

We certainly hope that it is the former and MSFT is keeping the news under wraps as we will be massively disapointed at Mix2011 if the "new IE" can't even fix the old IE's problems.

No ClueBat cannot be right if I can get IE to be as fast as other browsers,because it means there are other factors to be taken into account beside browser alone.

Like number of sites in Restricted zone (huge difference between ~10 and ~10 000 os sites)

And funny thing is all one needs to do is to follow common sense – few addons,defrag,no high activity apps (winrar,SVN,…) or runaway apps and you're set.

And it doesn't matter if it fresh install of Win or not.

As for high registry activity – lots of sites in RZ,lots of activity.

So to conclude:No troubles if your WIndows installation is in good order ,otherwise you need to first find out what is going on as IE newtab speed is by then just tip of iceberg.(And before complaining don't forget to check RZ for high no of items)

I don't like to troll again but users can see through "your same markup" illusion. Only a monopolistic company like Microsoft can conveniently ignore the rest 60% of the XP world. Hardware acceleration isn't critical to the standards-compliant rendering that every Windows user should have long got. With even Vista Home/Ultimate support ending in 2012, IE9 is more like an Ultimate Extra for Windows 7.

Sigh, would it be possible to update the blogging software on this site to somehow add filters for user accounts? I am truly tired of seeing posts on here about innerHTML and support for Windows XP. I truly get why XP is not being supported, and I support that move by Microsoft, and comments on innerHTML just aren't appropriate here.

There is small program with sourcecode – you'll need to change NEW_TAB_PAGE to correct text. my old timings are there BTW.

And last I will not give up,until these anecdotes stop and we start discussing evidence (measurments) and everybody understands that his results might be affected by issues outside of Microsoft control. And since there are poeple who don't have long startup time for new tabs in IE,it means that there is more probably problem in PC of reporter. And lastly what we hear are usualy only users who have troubles because those who don't ,don't see need to speak about it.(if they know about debate at all) – second bias in play.

===

So it is high time debaters would bring hard data to debate otherwise it is just political-type debate.

hims: There are plenty of complaints about slow Firefox due to add-ons. So many so that the Firefox team themselves blogged about it; there was a link to a post on that topic in the comments a few days ago.

hims: Heh,still selection bias – those who have no problems have no reason to talk. And how many of complainers have done tests and tried to understand what is going on. You seem to know some of them – link please(and not just generic "IE is slow") or run test yourself and report times.(along with specs of machine)

Just for good measure: D510,1GB RAM,SSD HDD: 125ms for first new tab and 109ms for next. Startup time of IE8 is about 5s (large RZ)

As for other browsers -those who have issue rarely complain too loud and just move to others. (Altough former FF users are quite a bit vocal about issues with FF)

I used for the first measurment on fresh system (about dozen starts of Windows) stopwatches – huge error margins like 500ms(distribution around correct time is unkown);reaction time of human is not that good.

That was why I dug up old Connect Ticket,so we had common method,which was repeatable.(the only time requiring stopwatches is startup of IE) And with that I published second set of )resutls from same machine. Not sure what changed (no updates or other installations nor changes to settings) but I got same times I got for other PCs.

Don't know what caused those 3s(what is left after correction for error margin),but it is away. And Frank even ignored my comment that RZ is huge.(Accounts for vast majority of registry access)

Note to those who have noticed the problem with the article title: Many feed readers aren't going to display the tags correctly. This is because of the naively ambiguous nature of RSS, which can contain XML-encoded HTML, but it's up to the feed reader/parser to auto-detect it, which is obviously not reliable.

Note to the IEBlog team: You should probably switch to an Atom feed (which unambiguously allows you to specify whether the content of an element contains HTML) if you plan on including tags in titles.