A Web without video would be a dull Web and consumers, developers and businesses want video on the Web to just work. As an industry we know this and have, until recently, been on a path to make this a reality with HTML5 by integrating video into Web pages more natively using H.264. There is more detail and discussion below but I want to be unambiguous on some key points:
IE9 will support H.264. Microsoft has released an add-on for Firefox on Windows to support H.264 and today we are releasing a plug-in for Google Chrome on Windows to provide support for H.264. We will provide support for IE9 users who install third-party WebM video support on Windows and they will be able to play WebM video in IE9. Many parties have raised legitimate questions about liability, risks, and support for WebM and the proponents of WebM should answer them. For context, Google recently stated (and then clarified) that their Chrome Web browser would drop support for the H.264 video format in favor of exclusively supporting Google’s new WebM format. There are many thoughtful articles questioning their decision, for example Google's dropping H.264 from Chrome a step backward for openness and The backlash over Google's HTML5 video bet and By dropping H.264, is Google avoiding a trap or walking into one?.
Setting aside the speculation about the reasons and objectives, this announcement has created instability and uncertainty around video on the Web. To get back on track, technical enthusiasts, developers, businesses, and consumers need consistent and sustainable answers to many questions about WebM. These groups also deserve to be part of an open discussion.
Below, we set out the main questions we’ve heard as part of the public conversation with many individuals and groups across the community and industry over the last few weeks and months. Broadly, the questions cover three areas:
Who bears the liability and risk for consumers, businesses, and developers until the legal system resolves the intellectual property issues; When and how does Google make room for the Open Web Standards community to engage genuinely; What is the plan for restoring consistency across devices, Web services, and the PC. We’ve been clear from the first public demonstration of IE9 that the community deserves a reliable platform for delivering video as part of the modern Web. The goal of this post is to raise the visibility of some of the legitimate questions that the community needs answered from WebM proponents in order for a new technology to become part of the Web standards we all rely on. The climate around intellectual property issues in general and video formats in particular is often highly charged. Anyone suspicious of Microsoft introducing “uncertainty, fear, or doubt” might examine the historical evidence of intellectual property issues around standards and media formats, some of which is covered below. That evidence should leave little doubt that what is needed is a more open dialog about these issues. Our public work on Internet Explorer has made clear our focus on providing the best implementation and validation of established Web standards, helping to move the Web platform forward, and providing the safest and most trustworthy browser for consumers who use Windows.
While this blog is focused on Internet Explorer, we think it is a good forum for a broader conversation about the browsers and technology that the community expects to all work well together. As part of the ongoing transparency in developing IE9, we’re using this forum to put forward questions for the broad community.
Microsoft’s Point of View and Plan for IE9 As context for the questions below, here’s a re-cap of Microsoft’s point of view and plan for IE9.
IE9 will play HTML5 video in the H.264 format. Why H.264? It is a high-quality and widely-used video format that serves the Web very well today. We describe many of those reasons in blog posts here, here, and here. Any browser running on Windows can play H.264 video via the built-in Windows APIs that support the format. Our point of view here is that Windows customers should be able to play mainstream video on the Web. We’ve provided Windows 7 customers who choose to run Mozilla Firefox an add-on to enable playing H.264 video on Web pages with the HTML5 video tag. Today we’re making available a similar plug-in for Google Chrome. IE9 users who install third-party WebM video support on Windows will be able to play WebM video in IE. We chose this path (supporting one additional video format that the user has installed on her machine) because we recognize that other video formats exist and we wanted to give customers a convenient way to view video in those other formats without specifying a particular one. With this approach, we provide a more stable platform overall given the many documented risks with arbitrarily downloaded video codecs including their use as vectors for malware and phishing. Our point of view is totally clear. Our support for H.264 results from our views about a robust Web and video ecosystem that provides a rich level of functionality, is the product of an open standards process like the W3C’s HTML5 specification, and has been free from legal attacks. Microsoft is agnostic and impartial about the actual underlying video format for HTML5 video as long as this freedom continues.
Our commitment to play WebM videos in IE9 for users who have installed WebM demonstrates our approach. We have worked closely with Google to help them deliver a WebM implementation on Windows and Google engineers are on the Microsoft campus this week; we appreciate their positive feedback to date around this work.
Industry Questions We want to make sure that what becomes a standard can stay a standard and that the standard serves the industry and customers well. An open dialog about the issues that come from new and unproven technology is an important part of how the Web works.
Let’s start with who bears the liability and risk for intellectual property?
Looking at video format support as a vote on who is for or against an open and free Internet is tempting but also naïve. Regardless of the debate on the interplay between patents and video formats for the Web, there is absolute certainty that some parties believe they hold valid and unique inventions (patents) and they will assert those rights if they think they are being infringed. Historically, providing new audio-video-image formats that are entirely free from infringement has been a lengthy and challenging process. Even when we have set out to do this ourselves, we have ultimately ended up being challenged. The targets of lawsuits around the JPEG image format, for example, included a shoe seller, an NFL franchise, and a company best known for its cheese. The real-world risks here apply broadly to many, many companies and agents. Wishing these risks away doesn’t work.
Offers of “free” or “royalty-free” source code and strong assertions that the technology is “not patent encumbered” don’t help when a patent holder files a complaint that your video, your site, or your product infringes on her intellectual property. The only true arbiter of infringement, once it’s asserted, is a court of law. Asserting openness is not a legal defense. Whether one supports open technology or not, there are practical liability issues today that need to be examined. These issues motivate different potential approaches to risk protection. One path is indemnification. For example, will Google indemnify Mozilla, a PC OEM, a school, a Web site, a chip manufacturer, a device company, or an individual for using WebM? Will they indemnify Apple? Microsoft? Will they indemnify any or all of these parties worldwide? If Google were truly confident that the technology does not infringe and is not encumbered by patents whatsoever, wouldn’t this indemnification be easy? It’s one way to move away from conversations about unknown and unbounded risk to a rational conversation about costs and liability. Whether one agrees or disagrees with the notion of software patents, the risk remains and the standard business practice of one party indemnifying another is well-understood. Or, does Google instead plan to protect WebM participants from risk by creating a patent pool containing the third-party intellectual property in WebM and making a license available? That is another way in which risks like this have been addressed in the past. What would the terms of that license be? Or, does Google plan to work with an existing patent pool to help provide Web developers get certainty quickly, as is already the case with H.264? These are difficult questions for sure, but they deserve answers if the Web community is to move from a well-established and successful video format for which the intellectual property landscape is more certain. We think the community is looking for meaningful answers to this risk question.
The risk question is a legitimate business concern. There are hundreds if not thousands of patents worldwide that read on video formats and codec technologies. Our experience with trying to release WMV for free and open use, and the subsequent claims against Microsoft, support this history as do the cases against JPEG, GIF, and other formats. By way of comparison, Microsoft provides and has even expanded the indemnification provided to end-users of Windows. Looking at the notes from a recent “WebM Summit” (here, slide 12), Google says that there are “No known royalty requirements.” That’s quite different from no royalty requirements, and the former might be a more accurate description of the IP situation.
These questions have many potential follow-ups. For example, Google’s blog posts have indicated a strong desire to use open formats for the video tag; will this pattern apply to plugins in general[…]

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles
}

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles
}

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

banner
main
contentinfo

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles
}

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

Tagged with
html5
css
aria
accessibility
standards
semantics

HTML5 is here to turn the web from a web of hacks into a web of applications – and we are well on the way to this goal. The coming year will be totally and utterly awesome if you are excited about web technologies.

This year the HTML5 revolution started and there is no stopping it. For the first time all the browser vendors are rallying together to make a technology work. The new browser war is fought over implementation of the HTML5 standard and not over random additions. We live in exciting times.

Starting with a bang

As with every revolution there is a lot of noise with bangs and explosions, and that’s the stage we’re at right now. HTML5 showcases are often CSS3 showcases, web font playgrounds, or video and canvas examples.

This is great, as it gets people excited and it gives the media something to show. There is much more to HTML5, though. Let’s take a look at one of the less sexy, but amazingly useful features of HTML5 (it was in the HTML5 specs, but grew at such an alarming rate that it warranted its own spec): storing information on the client-side.

Why store data on the client-side?

Storing information in people’s browsers affords us a few options that every application should have:


You can retain the state of an application – when the user comes back after closing the browser, everything will be as she left it. That’s how ‘real’ applications work and this is how the web ones should, too.
You can cache data – if something doesn’t change then there is no point in loading it over the Internet if local access is so much faster
You can store user preferences – without needing to keep that data on your server at all.


In the past, storing local data wasn’t much fun.

The pain of hacky browser solutions

In the past, all we had were cookies. I don’t mean the yummy things you get with your coffee, endorsed by the blue, furry junkie in Sesame Street, but the other, digital ones. Cookies suck – it isn’t fun to have an unencrypted HTTP overhead on every server request for storing four kilobytes of data in a cryptic format. It was OK for 1994, but really neither an easy nor a beautiful solution for the task of storing data on the client.

Then came a plethora of solutions by different vendors – from Microsoft’s userdata to Flash’s LSO, and from Silverlight isolated storage to Google’s Gears. If you want to know just how many crazy and convoluted ways there are to store a bit of information, check out Samy’s evercookie.

Clearly, we needed an easier and standardised way of storing local data.

Keeping it simple – local storage

And, lo and behold, we have one. The local storage API (or session storage, with the only difference being that session data is lost when the window is closed) is ridiculously easy to use. All you do is call a few methods on the window.localStorage object – or even just set the properties directly using the square bracket notation:


if('localStorage' in window && window['localStorage'] !== null){
var store = window.localStorage;
 
// valid, API way
store.setItem('cow','moo');
console.log(
store.getItem('cow')
); // => 'moo'
 
// shorthand, breaks at keys with spaces
store.sheep = 'baa'
console.log(
store.sheep
); // 'baa'
 
// shorthand for all
store['dog'] = 'bark'
console.log(
store['dog']
); // => 'bark'
 
}

Browser support is actually pretty good: Chrome 4+; Firefox 3.5+; IE8+; Opera 10.5+; Safari 4+; plus iPhone 2.0+; and Android 2.0+. That should cover most of your needs. Of course, you should check for support first (or use a wrapper library like YUI Storage Utility or YUI Storage Lite).

The data is stored on a per domain basis and you can store up to five megabytes of data in localStorage for each domain.

Strings attached

By default, localStorage only supports strings as storage formats. You can’t store results of JavaScript computations that are arrays or objects, and every number is stored as a string. This means that long, floating point numbers eat into the available memory much more quickly than if they were stored as numbers.


var cowdesc = "the cow is of the bovine ilk, "+
"one end is for the moo, the "+
"other for the milk";
 
var cowdef = {
"ilk":"bovine",
"legs":4,
"udders":4,
"purposes":{
"front":"moo",
"end":"milk"
}
};
 
window.localStorage.setItem('describecow',cowdesc);
console.log(
window.localStorage.getItem('describecow')
); // => the cow is of the bovine...
 
window.localStorage.setItem('definecow',cowdef);
console.log(
window.localStorage.getItem('definecow')
); // => [object Object] = bad!

This limits what you can store quite heavily, which is why it makes sense to use JSON to encode and decode the data you store:


var cowdef = {
"ilk":"bovine",
"legs":4,
"udders":4,
"purposes":{
"front":"moo",
"end":"milk"
}
};
 
window.localStorage.setItem('describecow',JSON.stringify(cowdef));
console.log(
JSON.parse(
window.localStorage.getItem('describecow')
)
); // => Object { ilk="bovine", more...}

You can also come up with your own formatting solutions like CSV, or pipe | or tilde ~ separated formats, but JSON is very terse and has native browser support.

Some use case examples

The simplest use of localStorage is, of course, storing some data: the current state of a game; how far through a multi-form sign-up process a user is; and other things we traditionally stored in cookies. Using JSON, though, we can do cooler things.

Speeding up web service use and avoiding exceeding the quota

A lot of web services only allow you a certain amount of hits per hour or day, and can be very slow. By using localStorage with a time stamp, you can cache results of web services locally and only access them after a certain time to refresh the data.

I used this technique in my An Event Apart 10K entry, World Info, to only load the massive dataset of all the world information once, and allow for much faster subsequent visits to the site. The following screencast shows the difference:

For use with YQL (remember last year’s 24 ways entry?), I’ve built a small script called YQL localcache that wraps localStorage around the YQL data call. An example would be the following:


yqlcache.get({
yql: 'select * from flickr.photos.search where text="santa"',
id: 'myphotos',
cacheage: ( 60*60*1000 ),
callback: function(data) {
console.log(data);
}
});

This loads photos of Santa from Flickr and stores them for an hour in the key myphotos of localStorage. If you call the function at various times, you receive an object back with the YQL results in a data property and a type property which defines where the data came from – live is live data, cached means it comes from cache, and freshcache indicates that it was called for the first time and a new cache was primed. The cache will work for an hour (60×60×1,000 milliseconds) and then be refreshed. So, instead of hitting the YQL endpoint over and over again, you hit it once per hour.

Caching a full interface

Another use case I found was to retain the state of a whole interface of an application by caching the innerHTML once it has been rendered. I use this in the Yahoo Firehose search interface, and you can get the full story about local storage and how it is used in this screencast:

The stripped down code is incredibly simple (JavaScript with PHP embed):


// test for localStorage support
if(('localStorage' in window) && window['localStorage'] !== null){
 
var f = document.getElementById('mainform');
// test with PHP if the form was sent (the submit button has the name "sent")
<?php if(isset($_POST['sent']))){?>
 
// get the HTML of the form and cache it in the property "state"
localStorage.setItem('state',f.innerHTML);

// if the form hasn't been sent...
<?php }else{ ?>
 
// check if a state property exists and write back the HTML cache
if('state' in localStorage){
f.innerHTML = localStorage.getItem('state');
}
 
<?php } ?>
 
}

Other ideas

In essence, you can use local storage every time you need to speed up access. For example, you could store image sprites in base-64 encoded datasets instead of loading them from a server. Or you could store CSS and JavaScript libraries on the client. Anything goes – have a play.

Issues with local and session storage

Of course, not all is rainbows and unicorns with the localStorage API. There are a few niggles that need ironing out. As with anything, this needs people to use the technology and raise issues. Here are some of the problems:


Inadequate information about storage quota – if you try to add more content to an already full store, you get a QUOTA_EXCEEDED_ERR and that’s it. There’s a great explanation and test suite for localStorage quota available.
Lack of automatically expiring storage – a feature that cookies came with. Pamela Fox has a solution (also available as a demo and source code)
Lack of encrypted storage – right now, everything is stored in readable strings in the browser.


Bigger, better, faster, more!

As cool as the local and session storage APIs are, they are not quite ready for extensive adoption – the storage limits might get in your way, and if you really want to go to town with accessing, filtering and sorting data, real databases are what you’ll need. And, as we live in a world of client-side development, people are moving from heavy server-side databases like MySQL to NoSQL environments.

On the web, there is also a lot of work going on, with Ian Hickson of Google proposing the Web SQL database, and Nikunj Mehta, Jonas Sicking (Mozilla), Eliot Graff (Microsoft) and Andrei Popescu (Google) taking the idea beyond simply replicating MySQL and instead offering Indexed DB as an even faster alternative.

On the mobile front, a really important feature is to be able to store data to use when you are offline (mobile coverage and roaming data plans anybody?) and you can us[…]

In 2005, Jesse James Garrett at Adaptive Path published the seminal blog "Ajax: A New Approach to Web Applications" and ushered in new age of web architecture. Ajax meant using the possibilities latent in JavaScript (specifically, the XMLHttpRequest object) so that a web page could contact the server asynchronously and request new data.

This was revolutionary; within months, we were seeing pages that were more dynamic and interactive. Ajax short-circuited the submit/response loop that dominated web applications up to that time. Instead of making an HTTP request, receiving an entire web page, and rendering that page as a replacement for the current page, the browser requested a chunk of data. It used that chunk of data to interact with the DOM and rewrite the page it was displaying on the fly.

Around the same time, the RESTful paradigm started taking hold. REST represented a much simpler, web-oriented way for servers to interact with their clients. As Roy Fielding pointed out in his dissertation, the basic operations of the HTTP protocol were capable of providing general access to data; stateful applications could be built upon stateless protocols; hypermedia could be used to maintain application state. Although Fielding's dissertation dates back to 2000, it took a few years of bad experience with SOAP and its heirs to realize its importance. With REST, it becomes easier for a website to see itself as a source of data for machines to process, rather than as a source of content for humans to read. Websites become data servers.

The HTML page you get from the new Twitter is largely a bunch of empty divs, with a big wad of JavaScript. The JavaScript is the entire application.

Important as Ajax and REST have been to the history of the web, each only represents half of a larger revolution. And in the past few months, we've seen some new sites that have taken the revolution to its logical conclusion. Specifically: take a look at the new Twitter. It's a nice web application, sure -- but look at the HTML. There's not much there. The HTML page you get from Twitter is largely a bunch of empty divs, with a big wad of JavaScript. What's happening? The JavaScript is the entire application; the divs exist only to provide tags so the JavaScript can rewrite the DOM at will. In turn, the JavaScript is constantly (and asynchronously) making requests from the Twitter site, which is just returning data from its API. In fact, the Twitter site is returning the same data for its web page that it would return for its mobile app, for TweetDeck, or for any of the apps in the Twitter ecosystem.

This design isn't particularly new; we've seen it ever since developers started reverse-engineering GMail and Google Maps to get ideas for their own projects. Those big Google apps may have been the first examples of this architectural trend. They were certainly among the first to use JavaScript as a full-fledge client programming language. But we're seeing many more sites built along these lines. Why now, what does this shift mean, and why is it important?

"Why now" is perhaps the easiest question to answer. A few short years ago, web developers only had one platform to support, and that was the "browser." Granted, there were a dozen or so browsers of significance, and the browser world was riddled with incompatibilities. We're in a different world now. Browser compatibilities have been ironed out, to some extent (though conscientious developers still support "legacy" browsers, all the way back to IE6 or even IE5). But it's no news that the most important new apps these days run on devices ranging from phones (iPhone, Android, BlackBerry, Windows Phone), tablets (iPad, Android/ChromeOS devices), and potentially ebook readers and other new devices. With these new devices on the table, browser incompatibilities pale in significance. It's another sign of the times that I can't conceive of an interesting application that doesn't access data across the network. A static application that never accesses remote data -- that's so 1990s.

So, while it's tempting to say that the new age is characterized by the browser as platform, and that applications running in the browser can do anything that native code can do, that's looking in the wrong place. HTML5 certainly ups the ante, as far as browser capabilities -- and is supported to some extent by all of the other devices we're concerned with. But the real meaning and importance of this architectural shift is on the server side, driven both by the need to support many heterogenous device and application types, and by the primacy of live data in modern applications.

Related books and videos

Ajax
-- Head First Ajax
-- Ajax, TDG

REST
-- Rest in Practice
-- RESTful Web Services
-- RESTful Web Service Cookbook

HTML5
-- HTML5: Up and Running
-- HTML5 Mobile Web Development (video)
In the browser-dominated world, static content and data were inevitably mixed. Yes, we had templating systems that let developers separate static content and design elements from data. But once the application server did its magic, what was delivered to the browser was HTML pages mixing data with other content. Browsers were similar enough that, with some browser detection hacks on both the server and client side, it was relatively easy (though a pain) to generate pages that would run anywhere. That doesn't work any more. It's naive to think that you can wrap some HTML around data and be done with the job; the chances are that you're leaving a huge chunk of your human audience behind, and making things more difficult for another audience -- machines that just want to consume your data. To build a modern application, developers must focus on the data: they must see themselves as data providers, they must develop documented and stable public APIs for accessing their data. Over the past few years, we've realized the importance of data. What's the value of Google without the data behind it? Or Facebook? Or, going back 15 or so years, GNN? It took a long time for us to understand the importance of data, as opposed to "content." But when you've gotten that lesson, your design goals change: designing and publishing a stable API to a data service becomes the highest priority.

That's the driving force behind this architectural shift. Front ends, user interfaces, clients, apps, whatever you decide to call them, don't disappear. But we have learned how important it is to keep the data interface separate from the user interface. Your next project will probably have multiple front ends, some delivered through HTML5, and some delivered through native code. Building them on a common data API is going to be much cleaner and simpler. In addition, third parties can build their own apps on top of your API. An important component of Twitter's success has been the ecosystem of applications that have built on their data: TweetDeck, TweetGrid, Tweetie, etc.; Twitdom, the Twitter applications directory, lists more than 1,800 apps. Until the "new Twitter" went live, the Twitter website was significantly less capable than most of the third-party apps.

Although it has been a long time coming, we're finally finishing the revolution that started with Ajax. Get data that users care about, make it available via an API, provide a data presence that's distinct from your HTML-based web presence, and build multiple front ends to serve your customers, on whatever platforms they care about. Your value is in the data.

Related:

What is data science?
The SMAQ stack for big data
Data as a service
Building data startups
Lies, damn lies, and visualizations

In previous posts, we described why IE9 will support H.264-encoded HTML5 video. Microsoft and other browser providers see hardware support, customer and partner readiness, and intellectual property rights as key factors making H.264 an excellent choice for video encoding and playback. These posts generated a significant amount of support and suggestions. This feedback together with today’s industry announcements create a good opportunity to follow up and provide more information about HTML5 video support in IE9.

In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows.

As we said at MIX recently, when it comes to HTML5, we’re all in. This level of commitment applies to the video codecs that IE9 will support as well. We are strongly committed to making sure that in IE9 you can safely view all types of content in all widely used formats. At the same time, Windows customers, developers, and site owners also want assurances that they are protected from IP rights issues when using IE9.

We have technical specifics to work through. We want to be clear about our intent to support the same markup in the open and interoperable web, and to do so in a manner consistent with our view of safety and security.

In the meantime, in choosing a video codec, customers and partners have many issues to consider.

Today, hardware support is widely available for H.264 both on PCs and phones. (You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here.) Codecs have been a source of security and reliability issues (link1, link2, link3, link4) for some users. New code often faces security issues; the H.264 codec in Windows 7 has been in broad use for some time now. Sites also need to think about the issues in supporting multiple formats.

As this article points out, the issue of potential patent liability is “ultimately for the courts to decide.” Some web groups have cited concerns about patent issues with similar codecs and the costs that may be associated with shipping codecs not covered by patent licenses. At the same time, there’s been community discussion about the lack of H.264 support in some browsers, for example here (via a comment on the IE blog).

Again, we want to be clear about our intent to support the same markup in the open and interoperable web. We are strongly committed to making sure that in IE9 you can safely view all types of content in all widely used formats. When it comes to video and HTML5, we’re all in. In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows.

Thanks, Dean Hachamovitch General Manager, Internet Explorer

Note: as we said in our prior post, comments are not available on the IE blog this week due to a system upgrade.  We always want your thoughts and feedback, so we cross-published this post on the Windows blog. If you want to comment on this post, click here.

Articles referenced in this post: Apple QuickTime H.264 Movie File Remote Code Execution Vulnerability Benefits of GPU-powered HTML5 Bugzilla@Mozilla – Bug 435339 (at comment 60) Bugzilla@Mozilla – Bug 435339 (at comment 79) How Much Web Video Is iPad-Ready? About Two-Thirds. Really. HTML5 video: Browser support (Wikipedia) IEBlog : Follow Up on HTML5 Video in IE9 IEBlog : Follow Up on HTML5 Video in IE9 (comment) IEBlog : HTML5 Video Keynote Day 2 :: Sessions :: Microsoft MIX10 (at the 26:35 mark) Know Your Rights: H.264, patent licensing, and you -- Engadget Microsoft fires back at critics of its HTML5 strategy | ZDNet Microsoft Intellectual Property Expansion: Frequently Asked Questions Nov. 10, 2004 Public Advisory: 04.09.10 // iDefense Labs SecuriTeam - Apple QuickTime H.264 Nal Unit Length Heap Overflow Vulnerability Use of Ogg formats in HTML5 (citation reference) (Wikipedia) [whatwg] Removal of Ogg is *preposterous*"

Edit 2pm: typo correction in the 4th paragraph.

SproutCore -- open-source HTML5 application framework (i.e., lots of Javascript goodness) that'll work with any backend. To code for this, you put most of the logic in the front-end and leave the back-end much simpler.
RDF for Intrepid Unix Hackers -- an interesting series, showing how to use common Unix tools to manipulate RDF data from the commandline. (via Edd Dumbill)
How to Thrive Among Pirates (Kevin Kelly) -- a look at how indigenous movie-makers make money in countries like China, India, and Nigeria where piracy is rampant. In short, they make cheap movies, sell near the price of inferior-quality knockoffs, and take advantage of unique experiences that movie theaters offer (e.g., air-conditioning).
On Complaints (PublicStrategist) -- a very good analysis of complaints departments and expectations of people who complain. But there is also a vital question of what the organisation thinks the purpose of a complaints process is. If it is a safety valve, a means of finding and correcting the most egregious failures or a means of channelling immediate anger and dissatisfaction into a swamp of unresponsiveness, then it can’t provide any broader value. That’s where the Patient Opinion model starts to look really attractive. It is deliberately and carefully constructed to elicit feedback, not just complaints. More than half the stories it gets told are positive, even some of the most harrowing, and it therefore creates a picture which is as clear about what is valued as it is about what is seen as in need of improvement.

In Issue No. 302 of A List Apart for people who make websites, Joe Clark explains what E-book designers can learn from 10 years of standards-based web design, and Daniel Mall tells designers what they can do besides bicker over formats.

Web Standards for E-books

by Joe Clark

E-books aren’t going to replace books. E-books are books, merely with a different form. More and more often, that form is ePub, a format powered by standard XHTML. As such, ePub can benefit from our nearly ten years’ experience building standards-compliant websites. That’s great news for publishers and standards-aware web designers. Great news for readers, too. Our favorite genius, Joe Clark, explains the simple why and how.

Flash and Standards: The Cold War of the Web

by Daniel Mall

You’ve probably heard that Apple recently released the iPad. The absence of Flash Player on the device seems to have awakened the HTML5 vs. Flash debate. Apparently, it’s the final nail in the coffin for Flash. Either that, or the HTML5 community is overhyping its still nascent markup language update. The arguments run wide, strong, and legitimate on both sides. Yet both sides might also be wrong. Designer/developer Dan Mall is equally adept at web standards and Flash; what matters, he says, isn’t technology, but people.

Illustration by Kevin Cornell for A List Apart.

When people say that the publication of HTML5 “blocked” by Larry Masinter’s “formal objection”, what exactly do they mean?

Why does the private w3c-archive mailing list exist? Why can’t anyone reveal what happens on there? What are the consequences for doing so? Who gets to be on that list in the first place?

Can anyone raise a “formal objection”?
Is anyone calling for the HTML Working Group to be “rechartered”? If so, what does that involve?
If there are concerns about the inclusion of Canvas 2D in the specification, why were these not resolved earlier?

Some background reading. I was planning to fill in answers as they arrive, but I screwed up the moderation of the comments and got flooded with detailed responses—I strongly recommend reading the comments.

Plupload (via). Fantastic new open source project from the team behind TinyMCE. Plupload offers a cross-browser JavaScript File uploading API that handles multiple file uploads, client-side progress meters, type filtering and even client-side image resizing and drag-and-drop from the desktop. It achieves all of this by providing backends for Flash, Silverlight, Google Gears, HTML5 and Browserplus and picking the most capable available option.

Real time online activity monitor example with node.js and WebSocket. A neat exploration of Node.js—first hooking a “tail -f” process up to an HTTP push stream, then combining that with HTML 5 WebSockets to achieve reliable streaming.