The WHATWG never planned to stabilize in 2022. Ian Hickson, the editor of HTML5, predicted that it would take until 2022 to reach the equivalent of W3C Recommendation status: where every single feature has at least two independent implementations, plus a full test suite (which would require hundreds of thousands if not millions of tests for such a large spec). The spec becomes basically stable at the Candidate Recommendation stage, which Ian originally predicted to be 2012 (and that looks to be plausible so far). You can read more about this in the WHATWG FAQ.

SVG is a declarative vector graphics format, while canvas is an immediate-mode 2D graphics API for JavaScript. Using SVG for a dynamic web application is kind of ridiculous – something as simple as ctx.fillRect(x, y, w, h) to draw a rectangle would require several lines of DOM methods.

You can stream live video just fine, if the format and browser supports it. I've heard reports of people getting this to work just fine with Ogg. This isn't the big use-case anyway, though.

You can full-screen HTML5 video in Firefox 3.6 and later (IIRC) via the context menu. There's no standard JavaScript API to full-screen the video yet, because no one has worked out the security implications in enough detail yet: you'd have to design it carefully so that malicious scripts can't take over the screen (maybe just by copying what Flash does). WebKit has an experimental API in that regard. Plus, you can always just make the <video> tag fill the screen and let the user hit F11 if they want – YouTube does this, and it works pretty well (although it's not ideal).

HTML5 video is not yet usable as the only video format anyway, since you have to support IE

4. You can't seek in videos in anything remotely near a reliable manner. You know how you can link to a certain time in a Youtube video? Not possible in HTML5.

It's perfectly possible. YouTube has some JavaScript that will automatically seek the Flash video based on the fragment, and they could do exactly the same for HTML5 video. Seeking is as simple as setting video.currentTime. YouTube already uses this attribute to make its custom seek bar work.

Of course you can. Just record currentTime, change the src, and then set the new currentTime. This is all trivial from JavaScript, much easier for a typical web developer than trying to communicate with Flash.

HTML5 is a vast spec that includes a huge number of improvements and refinements. The HTML5 parsing algorithm, for instance, will make a lot of weird websites work exactly the same across browsers when formerly they all behaved a bit differently – it's enabled by default in Firefox 4, and experimentally available for WebKit. This and many other clarifications are giving each new browser release more opportunity to be consistent with other browsers.

Canvas, video, and audio are not yet as reliable, widely available, or full-featured as their plugin-based equivalents, but they're suitable at least as fallbacks where the plugins aren't available (iOS, sometimes Linux). SVG and MathML embedded in HTML (not XHTML) documents are usable on some cutting-edge browsers, with painless ways to fall back to rasterized versions (requiring barely more work than just using the rasterized version). Microdata can be used today and some search engines will recognize it.

(Yes, you can do some of the above using plugins. But plugins don't work on iOS, don't work reliably on Linux, and don't integrate well with the page. If you want to do Flash video, you have to script it in ActionScript, not JavaScript. Plugins tend to have all sorts of nasty warts, like not obeying CSS or trapping commands that the user intends the browser to receive. I've seen Flash videos display on top of random content that was supposed to overlay the video, and I hate when keyboard shortcuts stop working when I have anything Flash focused. It's just a lousy solution.)

HTML5 includes a lot of nice little things that can easily be used to augment your existing pages without too much work, while keeping your legacy code for legacy browsers. Examples of this are the autofocus attribute, the placeholder attribute, and getElementsByClassName(), all of which are supported in recent enough Firefox and WebKit (for instance).

And it also makes a lot of convenient things valid that browsers already supported anyway. This includes <meta charset="">, omitting quote marks and closing tags in more cases than HTML 4 permitted, standardizing innerHTML, standardizing contenteditable (although not precisely enough for real interop yet), standardizing autocomplete, and permitting custom attributes if they start with "data-".

I encourage you to read the Editor's Draft of HTML5 differences from HTML4 for a more comprehensive list of what HTML5 adds. Many of these features are supported in enough browsers to be useful today, which is why some HTML5 features are used by practically all major sites and all up-to-date JS libraries. There is no reason not to use the things that are useful today, which is a fairly decent amount – although nothing compared to what we'll be seeing five years from now when big features like canvas and video/audio are better-developed and more reliably available.

And, of course, all of this only talking about the HTML5 spec proper. If you include all the other things that are often labeled "HTML5", there's tons more to talk about: CSS3, Web Storage, Web Databases, WebSockets, and a host of other features. This is a time where the web is moving forward at a very rapid pace, in sharp contrast to the stagnation we saw five to ten years ago – and yes, quite a lot of features are already usable to some degree.

You're not getting what's I was testing. Opera prints the password in cleartext when you do what I described, no other browser does. Firefox 4 nightlies print an unhelpful error message (unhelpful because I provided no title attribute on the input element, for brevity, otherwise it would be helpful), and everything else just submits the form, but nothing else prints the password.

I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.

And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:

data:text/html,<form><input name=foo type=password pattern=...><input type=submit></form>

Then type one or two letters in the password field (not more) and try to submit. So, Opera's great and all, but its implementation of this stinks.

Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.

Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.

HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.

Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.

The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.

This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.

The W3C Process, on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.

(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles.)

The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.

So it's mostly a matter of limited programming time, nothing mysterious.

Your average sysadmin (or even your above-average sysadmin) is going to be pretty hard-pressed to figure out which services a given library vulnerability "really" affects. Without really understanding the code, it's hard to say. The only safe thing is to restart everything.

Sure. You just have to restart everything using libc, like for instance:

$ sudo lsof -c init 2>/dev/null | grep libc
init 1 root DEL REG 251,0 269825 /lib/tls/i686/cmov/libc-2.11.1.so

Notice how it's deleted, so presumably init is using an old libc version that was upgraded. Hope it doesn't contain vulnerabilities! If you can't tolerate rebooting your system, you probably can't tolerate restarting every single process, either. And if you can leave unpatched libc running in all these daemons, why not an unpatched kernel too?

All that said, it would be nice if distros could apply patches live automatically for the benefit of regular users, who ignore the "please reboot" message (or even just take hours to notice it). At least it will reduce vulnerabilities. But this can't fairly be billed as a way to avoid rebooting altogether, which is how it's often presented: "No More Need To Reboot". Wrong.

Okay, this is a legitimate point. If you use clustering or something, then you might be immune to most hardware failures. Even if you use regular hardware, if you have enough hardware redundancy you're only subject to CPU/RAM/motherboard failure, and most of that's hot-swappable for upgrades with the right OS. Not perfect, but say planned downtime once per five or ten years for an OS upgrade, probably acceptable. It's possible.

But it's much more common these days to just design systems you can reboot nodes without downtime, so I don't see hot-patching allowing "No More Need To Reboot" except in a very small minority of setups. Better to think of it as a tool to increase security by letting you deploy patches faster.

I run a 16-core server with 16 GB of RAM. I'm going to deploy a second one soon with automatic failover to eliminate downtime for routine administration. It's perfectly possible for the vast majority of services. I'll grant that there will always be exceptions, probably for the most part custom-written applications that weren't designed for redundancy.

You can't reboot one mainframe at a time without affecting service, if you only have one mainframe. Rebooting it's going to leave you with no running servers, and it's hard to provide service then. :) Instead, you're forced to design the system so you never have to reboot it, which is much harder.

And for hardware failures? Or critical service restarts? Or a bug causing an OS crash? Put it this way: you can either try to minimize the downtime of each server, or make it so that the downtime of one server doesn't affect service. The former is much more complicated and error-prone, and is still going to fail sometimes, so you need the latter regardless if you're really aiming for reliability. And the latter makes the former unnecessary.

The difference between mainframes and regular PCs is that one mainframe's role is taken on by many PCs. With proper setup, you should have redundancy between the PCs, so you can reboot them one at a time without affecting service. You can't do that if you only have only one mainframe. Even with two, you can only do it if you can afford to double your load. So this might be needed for mainframes, but not for PCs.

Okay, so even suppose this is perfectly reliable. Let's say I'm running a high-availability server and can't stand any downtime. Now when my kernel needs an update, I don't have to reboot, great!

So what about when, say, libc needs an update? As long as programs are still using it, they'll be using the outdated version. Am I supposed to restart all programs using libc? That will cause downtime just like a reboot (although maybe a bit less).

Or what about when I need a hardware upgrade? Or there's a hardware failure? Or what happens when that critical application requiring 100% uptime needs a security fix? What am I supposed to do then?

There's no way to avoid outages completely for any given machine. PC OSes aren't meant for that. Any high-availability service needs to be able to tolerate the failure of any one machine. So why not just reboot it when you get a critical update to the kernel or major system library? That way you know that the machine reboots properly, too.

My suspicion is that this is mainly meant to lure in Linux users who want the "please reboot your computer" messages to go away. But those messages are misleading. If you Ksplice and never reboot, your libraries will remain outdated indefinitely – it's not secure. Distros would do better to ask for reboots only on security updates, and to do so for libraries and running applications (if they can't be easily restarted) as well as kernel updates.