A bit like how Gmail, Twitter, or many other sites don't use the document fragment identifier to do such a thing. Or a bit like how there's no such thing as history.pushState() to implement that (and because it doesn't exist, it doesn't work in Google Chrome, but if it did, it would work perfectly).

Yep, sometimes you have to break the back button.

I don't get why that is an issue. If you want to write clean markup, write clean markup. And today's browsers are perfectly capable of handling all manner of weird and wonderful markup.

The only situation I can think of where lax HTML5 markup would cause you a problem is if you're deploying to a custom mobile device or custom-written browser for a specific deployment. But in that case, you'd likely have control over both the input and output, in which case what I said above -- just write damn clean markup -- still applies.

If I saw problems with my browser struggling to render all the HTML5 content out there, I'd agree with you. But the reality is that browsers are mature, and can deal with the markup out there. And those that are writing markup are testing. It's a cycle that is working in practice, not just theory.

There is nothing stopping you from using well-formed XML in your HTML5, or serving your document as application/xhtml+xml (explicitly stated in the HTML5 spec). Serving HTML5 as proper XML is dubbed "XHTML 5". It uses the same doctype. All the new tags -- video, audio, section, header, etc. are supported, but obviously the lax markup features of HTML5 (like being able to omit most tags) no longer apply.

That's a very encouraging statistic. To the GP: Jeff Rosen (one of the guys behind Wolfire) wrote an enlightening blog post ("Linux users contribute twice as much as Windows users") on the subject too.

You should definitely read more of the Wolfire Blog. One of my favourite posts is about their reasoning for why you should support Mac OS X and Linux.

Mac OS X optionally includes a case-sensitive file-system, so as with OpenGL, once ported to OS X, it should be trivial to port that area to Linux.

That said, one of the Adobe CS versions crash when installing on a case-sensitive file system (find a link yourself -- I can't be bothered at this time of the morning), and Haiku won't build unless you build on a case-sensitive file system.

Except OpenVPN doesn't support IPv6 transport yet. You can run IPv6 inside the tunnel, but not outside.

Though there is a patch or two floating around that does add this feature (and will presumably be added to OpenVPN unstable soon if not already).

I don't have that Google statistic, but I do know that Wikimedia run similar tests on Wikipedia. Here are the test results, updated daily. As of today, 2010-03-28, an AAAA breaks the request 0.39% of the time for Wikipedia users.

Those tests are done in the background to users at random by a snippet of JavaScript on Wikipedia articles.

This Google presentation says Google would lose 0.1% of traffic if they added AAAA, though it's not presented particularly prominently, so take that with a grain of salt.

Either way, adding AAAA's will break your website for some people. In my opinion, though, the number is so small it's not worth worrying about, but each to his own, I guess. All this pain will be over soon anyway. Hopefully.

Such as my ability to determine that in one of your aforementioned videos, they are actually still serving the Flash widget, despite being opted-in to the HTML5 beta. (I suspect that videos that they haven't transcoded to H.264 get served as Flash still, but that's just a guess.) Right-click on it and see.

Could have double-checked that before flinging the word "stupid" at me, but hey -- takes one to know one.

Because your personal testimony counts for...oh wait. Nothing. You've already been told not to guess once. Take this as your second warning.

I'll believe it when I see it. Until you provide some sort of proof (URL to non-H.264 and non-FLV YouTube video would be nice), I won't believe that.

Opera uses GStreamer as a backend, and 'will also be able to use "anything that Gstreamer can handle,"'. What quite likely actually happened was that the video in fact was H.264, and was using the H.264 decoder in your system's GStreamer.