to the bottom of your page to stop you trying to hide their adverts, it could be good to add <plaintext style="display: none"> to your page just before the point where they add their junk. plaintext is the unstoppable monster of HTML – there is no closing tag, and the rest of the page will be treated as plain text instead of HTML. It's a slightly obscure feature, but it has better support between web browsers than many other parts of HTML and it can be fun to play with...
There's one good feature of XHTML, today, in my opinion: parsing is cheaper for Microformat consumers. Good HTML parsers are hard to come by, XML parsers are a dime a dozen.
I believe that's a good feature of HTML5 too: there are already parsers in Python, Ruby, Java, PHP, and partial ones in C++ and JavaScript, and maybe some others, all implementing the same specified algorithm (and passing the same set of test cases) and being sufficiently compatible with real-world HTML pages. I don't suppose they'll ever be as numerous as XML parsers, but it already seems a significant improvement compared to the pre-HTML5 parsing situation and hopefully people will no longer claim that XML is significantly easier and faster to parse than HTML.
That mechanism wouldn't degrade acceptably in non-HTML5 browsers, since the <shieldson> would just be ignored – so nobody could use it now (or for the next ten years or so) without subjecting a significant number of their users to exactly the unsafe content that they want to protect against. As far as I'm aware, nobody has come up with another mechanism that would work well enough and that doesn't require more effort on the server than simply doing all the HTML escaping there.
A new security mechanism implemented in browsers will still have bugs, so nasty stuff may still sneak through, and since it's in the user's browser you can't even fix it (except by blocking visitors and telling them to upgrade). Server-side solutions can be much more easily adapted to handle changes, without multi-year upgrade cycles.
New tags aren't introduced very often - it has been ten years since HTML4, and HTML5 isn't anywhere near finished yet. When they are introduced, old server-side HTML escaping code would just treat them as unsafe (since you have to use a whitelist of acceptable elements anyway, because it's not feasible to enumerate badness), so it will still be safe for the user.
On the other hand, browser developers are probably more competent than most web developers, so moving the handling of security issues into the browser instead of the site is a good thing - it seems the problem in this case is that nobody has found a way to make it work well within the technical constraints of HTML, and browser developers aren't interested in very long-term solutions which assume everyone implements HTML5. I'm not at all certain who's right here.
Microsoft can't change how IE handles web pages, because they will break all the sites that were written to depend on IE6's behaviour. They did make some changes in IE7, but they were burnt by the experience and don't want to do it again - see Chris Wilson's comments:
IE7 did cause widespread disruption, as a case in point. I championed making those widespread changes to improve our standards compliance. In all seriousness, I've managed to hang on to my job, but sometimes I think only just. I cannot go to my team and say "hey, we're gonna break the web again (and again and again), but it's okay because it's for a good cause." The world doesn't work that way. I wouldn't be responsibly doing my job - that one where half a billion web users rely on my team to not hose compatibility with their banking web site, even if their bank doesn't know how to properly use CSS 'float'.
All the other browsers do reverse-engineer IE's behaviour, as well as each other's. HTML 5 is largely an attempt to document and standardise that reverse-engineering: anyone who wants to process the web has to do it in a way that's compatible with the real web, and the real web is written to be compatible with IE, so that has always been the de facto standard and now HTML 5 is making it into a real standard.
There are many cases where IE's exact behaviour is too insane to copy, but Mozilla and Opera and Apple have experience of what behaviour is close enough to work in reality (based on feedback from bug reports about broken sites) - so the result is something that should be sufficiently compatible with IE in all the cases which web authors depend on.
There was some discussion about that on the WHATWG list here that may be interesting. (The list is open for anyone to subscribe and post to, if you have points to add to the discussion about this or other features.)
You can create DOMs that cannot be serialised to well-formed XML, like with document.createComment('--'). I don't really know anything about XSLT, but it doesn't appear to have had much success as a web templating language. Tools like Genshi seem to do much better at that, but anything outputting XHTML has to be very careful about avoiding all the little errors that might creep in and kill the document, so it's still safer to serialise to HTML at the output end of an XML toolchain - the browsers of your web site's users are rarely the best place to detect bugs in your server code, since those users are not in a position to do anything except leave your site.
What benefits does XHTML-served-as-HTML have over HTML, in terms of semantics and accessibility?
You can't use real XHTML features, like the ability to embed SVG, MathML, Ruby etc into your document, because you're limited to the subset that is compatible with real-world HTML. (That's "real-world" since XHTML-as-HTML is necessarily incompatible with theoretical HTML - HTML4 is defined as an application of SGML, in which "<br/>" is equivalent to "<br>/", which causes problems if you ever try handling XHTML-as-HTML using SGML tools (like the W3C Validator), and everyone using XHTML-as-HTML is relying on the unspecified non-standard behaviour of web browsers.)
I can't see how XHTML1 (even correctly served as XHTML) is more semantic than HTML4: it uses exactly the same elements and attributes with exactly the same meanings. I also don't see how it helps accessibility: it seems most assistive technologies just read the rendered document out of the web browser, and they don't care whether it was sent over the wire as HTML or as XHTML, and in any case there is not a significant difference between writing an HTML parser and writing an XML parser.
Client programs can't use XML processing tools, since the majority of XHTML-served-as-HTML on the web is not well-formed and won't work unless you treat it as broken HTML. XML tools can be useful on the server but you might as well stick an HTML serialiser on the end before you send it to clients (which is no harder than sticking an XHTML-served-as-HTML serialiser on the end), since the underlying language is identical and HTML is better supported.
If no browser accepts it, the developer will have to fix it or get fired.
More likely, the developer will stop using technology that makes their life harder, and will stick with invalid HTML4 and Flash and Silverlight and all the other possibilities, which defeats the aim of improving interoperability on the web.
Also, browsers have bugs. What happens when a user tests in one browser which accidentally accepts their invalid code, without noticing that other browsers don't? (Possible answer: other browsers will have to start accepting that invalid code too, else their users will stop using that browser and start using the one that can actually display the web. And since the specification would only say how to handle valid code, the other browsers will have to reverse-engineer each other to get mostly-compatible behaviour for invalid code, which results in a mess of incompatibilities - that is what has happened for HTML4, and is what HTML5 is trying to fix by defining how all invalid content must be handled in a way that is sufficiently compatible with the existing behaviour (and existing bugs) of browsers.)
Also, most content is generated dynamically, so you can't simply test the page before you upload it. Server-side code has bugs, and draconian error handling does not make things easy to fix.
HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.
That is incorrect: the HTML5 parsing algorithm never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).
Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.
As well as Flash, you can do HTML and JavaScript and graphics in <canvas> – I experimented with an FPS engine a while ago, and developed it just with desktop versions of Opera and Firefox, and reportedly it actually works on the Wii too. (Recent nightly builds of Safari also support it – it's nice when browser interoperability works.)
It's quite horrifically inefficient doing all this in a web browser rather than C++, but there's still a lot you can manage that's within the bounds of feasibility, if you use some imagination to simplify what you need the technology to do for you.
Incidentally, I like the idea of supporting open standards like <canvas> and <video> rather than proprietary platforms like Flash, particularly given that everyone using the Wii browser has to (indirectly) pay for licensing the Flash player from Adobe.
The API is reminiscent of the WHATWG Storage Specification
The Database module is also reminiscent of the HTML5 Client-side database storage, which was added to the spec about a week ago. (Hmm, coincidence?)
The spec is currently very under-defined, but the intent is that some implementations (at least Firefox) will ship with it implemented using SQLite, and then people will start using it, so SQLite's dialect of SQL will become the de facto standard and everyone else has to implement it the same and then that will be specced.
Google Gears is using SQLite too, and the API is pretty similar, so it would be an interesting way to implement the HTML5 executeSql in older browsers.
That isn't a problem. Apple and Microsoft (and Mozilla and Opera and others) are part of the W3C's new HTML Working Group, which is going to take the WHATWG's work (including canvas) and build on that (hopefully not by removing canvas in the process); and the W3C has a patent policy which means Apple's patent is not a problem, since they will follow that policy and make it freely usable by anyone implementing the specification. (The WHATWG doesn't have a patent policy, which is why Microsoft didn't get involved until it moved into the W3C.)
Yep, but the spec saying "3D would be cool" is a long way off actually doing any work on it - there was a bit of discussion on the mailing list some years ago, but (as far as I'm aware) nothing else has been done within the WHATWG since then. (And all the work is done in the open, so it would be obvious if they had done any.)
In any case, Microsoft is staying out of the WHATWG because of the lack of a patent policy, but they're involved in the HTML WG and seem to be interested in pursuing the HTML5 work now. I expect the 3D canvas work would be done in the WHATWG instead (as it seems much more productive than the HTML WG) and so Microsoft wouldn't be able to get involved even if they cared; but I expect that the 2D canvas will end up in the W3C spec, which will hopefully give Microsoft enough reason (and enough assurances about avoiding patent lawsuits) to implement it at some point in the future. But that'll probably be years in the best case, and 3D seems further out... In the meantime, I'll just keep making sites that work in everything except IE:-)
the OpenGL API for the Canvas tag that the WHATWG has been working on
Only a minor point to clarify, but the WHATWG hasn't been working on the OpenGL API, and the 2D canvas (which it has worked on, and which has been implemented) isn't designed to be hardware-accelerated. Some Firefox and Opera developers have been experimenting with exposing OpenGL ES, and it seems likely that they will propose it in the WHATWG at some point to get standardisation, but that hasn't happened yet and it isn't much of a priority, and I expect it will take quite a while to get it sorted out.
(I've done some work with pseudo-3D in the 2D canvas, which is kind of slow, so I'm quite interested in how it's going to progress in the future.)
Unfortunaely I can't find the name of a program that aired in the UK about 6 months ago. It took a team of 4 people to a deserted island and each week they had a task to complete each, they were only allowed to use what was on the island and what was given to them each week (as well as a tool set because, well no tools = screwed). They had to do things like make fireworks, record a song and various other "minor" things which required them to render down various things to achieve the chemicals they needed to complete each task. What they did and what it resulted in was very clearly labeled, having real science explained behind it.
Would that be Rough Science? In particular, it sounds like the second series. I've seen a couple of the series over the past few years, and I believe it did a pretty good job of being a science show – the interest comes from watching people who actually know what they're doing, designing and building ingenious solutions (admittedly with very convenient tools and materials available) to problems that aren't inherently interesting (like making toothpaste or measuring the speed of a glacier), rather than relying on 'interesting' problems that are large/dangerous/explosive and lacking focus on the solution process.
Not quite valid – title is required. But I think the removal of the copy-and-paste doctype/meta strings (and script/style type, etc) is definitely nice for anyone writing pages by hand.
HTML4 says the default value for input's type is "text". Since HTML4 browsers don't recognise "email", they use the default instead, which gives a plain text box. (HTML4 is generally under-specified, so it doesn't actually say what should happen when a unrecognised value is given, but everybody implements it in the same way.)
You'll always have to do server-side validation – but users will have a nicer experience if errors are immediately flagged in a standard way by their web browser, rather than having to go through a slow round-trip to the server before being told they made a mistake. The browser can also provide some UI to let people quickly enter their own email address into the box, or to copy one from their address book.
I think the fact that it's a work-in-progress is the relevant factor to consider when wondering why people aren't using it.
That's not a relevant factor for the Safari developers to say "the HTML standards process has been moribund; the W3C's HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice" and "We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web". As far as I am aware, Mozilla, Opera and Microsoft are all not planning to ever implement XHTML2, whereas they are already working on HTML5 – HTML5 also has many features that are work-in-progress and which nobody is using yet, but which the browser vendors are already implementing, because they are valuable changes and don't break compatibility with the current hundred billion documents on the web.
A fundamental design principle of HTML5 is that HTML5 pages should work in existing browsers like IE6. You can write <input type="email">, and an HTML5 browser will allow useful auto-filling and immediate validation feedback, while old browsers will simply show a text box. New elements like <video> can have fallback content, e.g. to embed a Flash video player. New elements like <canvas> can be partially implemented by JavaScript in IE6. The HTML5 doctype (<!DOCTYPE HTML>) is chosen so that it triggers standards mode (as opposed to quirks mode) in all existing browsers.
So, you can write in HTML5 to provide added benefits for users of browsers that understand HTML5, while still being no worse than before for users of older browsers. And given that IE development has started up again, with IE7 making some progress on CSS standards compliance, and given that Microsoft is a member of the W3C's HTML working group which will almost certainly accept the current HTML5 work (as it was the reason for the working group to be formed, and nobody has raised any serious objections since it was proposed), I believe there is reason to be hopeful.
As it happens, that multipage version is one I hacked together yesterday, using the html5lib parser and an HTML5 innerHTML-like serialiser. The original and more-official version of the spec (from which the multipage one is derived) validates as HTML 4.01 Strict - the only problem is that it's quite large and makes browsers unhappy, hence the new multipage version.
(The multipage one does conform as HTML5 - but the conformance checker and the spec are still far from stable, so that doesn't mean a lot.)
Acid2 is only testing the error handling that is required by the standards – it is necessary that browsers support the error handling properly so that future standards can extend the language in a backward-compatible way. To a browser that was written to support CSS2, pages that use CSS3 will look like invalid nonsense; but since CSS defines the error handling, CSS3 can be designed so that it will fall back gracefully for users who only support CSS2 (and even CSS1), and it will be relatively painless to adopt the improvements. That's why it's important to specify and to test the error handling.
If you want Firefox with its original advantages and just its original features, why not use the original Firefox? Meanwhile, those who can benefit from the new technology will do so.
The only reason I can think of is that the old versions have unpatched security problems, so you'll want to upgrade after they're unsupported – but if you want the Firefox developers to stop adding new features, they're not going to still fix the security problems, they'll just move to more interesting and worthwhile projects and Firefox will die. Firefox has inertia now – and the whole web is gaining inertia, after stagnating during IE6's dominance, with even the W3C restarting realistic work on HTML – so it would be a waste if it didn't continue to grow and change.
In any case, they are planning to make future versions of Firefox faster and more secure and make the code less crufty, with better C++ usage and a better garbage collector to fix memory leaks and a new JavaScript VM. And Firefox is still only a 6MB download – it's not exactly the heaviest of programs you'll ever download.
VMware engineers also don't put any faith into being able to hide the fact that the guest OS is virtualised. When there are unavoidable holes like timing differences, there's no value in hiding some of the other avoidable holes.
But now they have an answer to the question "congratulations, you now know you're on a VMware Workstation 4.5 VM. What are you going to do about it?"
But qubits are a superposition of the two binary states – they're a|0> + b|1>, where |0> and |1> are linearly independent vectors in the state space, and a and b are complex numbers. I don't see why you couldn't have a third independent vector, giving qutits (?) of the form a|0> + b|1> + c|2>, and it probably doesn't even make the maths much harder; but binary qubits are easier to find in the physical world, such as the polarisation of photons.
Slashdot Mirror
I believe that's a good feature of HTML5 too: there are already parsers in Python, Ruby, Java, PHP, and partial ones in C++ and JavaScript, and maybe some others, all implementing the same specified algorithm (and passing the same set of test cases) and being sufficiently compatible with real-world HTML pages. I don't suppose they'll ever be as numerous as XML parsers, but it already seems a significant improvement compared to the pre-HTML5 parsing situation and hopefully people will no longer claim that XML is significantly easier and faster to parse than HTML.
That mechanism wouldn't degrade acceptably in non-HTML5 browsers, since the <shieldson> would just be ignored – so nobody could use it now (or for the next ten years or so) without subjecting a significant number of their users to exactly the unsafe content that they want to protect against. As far as I'm aware, nobody has come up with another mechanism that would work well enough and that doesn't require more effort on the server than simply doing all the HTML escaping there.
A new security mechanism implemented in browsers will still have bugs, so nasty stuff may still sneak through, and since it's in the user's browser you can't even fix it (except by blocking visitors and telling them to upgrade). Server-side solutions can be much more easily adapted to handle changes, without multi-year upgrade cycles.
New tags aren't introduced very often - it has been ten years since HTML4, and HTML5 isn't anywhere near finished yet. When they are introduced, old server-side HTML escaping code would just treat them as unsafe (since you have to use a whitelist of acceptable elements anyway, because it's not feasible to enumerate badness), so it will still be safe for the user.
On the other hand, browser developers are probably more competent than most web developers, so moving the handling of security issues into the browser instead of the site is a good thing - it seems the problem in this case is that nobody has found a way to make it work well within the technical constraints of HTML, and browser developers aren't interested in very long-term solutions which assume everyone implements HTML5. I'm not at all certain who's right here.
Microsoft can't change how IE handles web pages, because they will break all the sites that were written to depend on IE6's behaviour. They did make some changes in IE7, but they were burnt by the experience and don't want to do it again - see Chris Wilson's comments:
All the other browsers do reverse-engineer IE's behaviour, as well as each other's. HTML 5 is largely an attempt to document and standardise that reverse-engineering: anyone who wants to process the web has to do it in a way that's compatible with the real web, and the real web is written to be compatible with IE, so that has always been the de facto standard and now HTML 5 is making it into a real standard.
There are many cases where IE's exact behaviour is too insane to copy, but Mozilla and Opera and Apple have experience of what behaviour is close enough to work in reality (based on feedback from bug reports about broken sites) - so the result is something that should be sufficiently compatible with IE in all the cases which web authors depend on.
There was some discussion about that on the WHATWG list here that may be interesting. (The list is open for anyone to subscribe and post to, if you have points to add to the discussion about this or other features.)
You can create DOMs that cannot be serialised to well-formed XML, like with document.createComment('--'). I don't really know anything about XSLT, but it doesn't appear to have had much success as a web templating language. Tools like Genshi seem to do much better at that, but anything outputting XHTML has to be very careful about avoiding all the little errors that might creep in and kill the document, so it's still safer to serialise to HTML at the output end of an XML toolchain - the browsers of your web site's users are rarely the best place to detect bugs in your server code, since those users are not in a position to do anything except leave your site.
What benefits does XHTML-served-as-HTML have over HTML, in terms of semantics and accessibility?
You can't use real XHTML features, like the ability to embed SVG, MathML, Ruby etc into your document, because you're limited to the subset that is compatible with real-world HTML. (That's "real-world" since XHTML-as-HTML is necessarily incompatible with theoretical HTML - HTML4 is defined as an application of SGML, in which "<br />" is equivalent to "<br>/", which causes problems if you ever try handling XHTML-as-HTML using SGML tools (like the W3C Validator), and everyone using XHTML-as-HTML is relying on the unspecified non-standard behaviour of web browsers.)
I can't see how XHTML1 (even correctly served as XHTML) is more semantic than HTML4: it uses exactly the same elements and attributes with exactly the same meanings. I also don't see how it helps accessibility: it seems most assistive technologies just read the rendered document out of the web browser, and they don't care whether it was sent over the wire as HTML or as XHTML, and in any case there is not a significant difference between writing an HTML parser and writing an XML parser.
Client programs can't use XML processing tools, since the majority of XHTML-served-as-HTML on the web is not well-formed and won't work unless you treat it as broken HTML. XML tools can be useful on the server but you might as well stick an HTML serialiser on the end before you send it to clients (which is no harder than sticking an XHTML-served-as-HTML serialiser on the end), since the underlying language is identical and HTML is better supported.
More likely, the developer will stop using technology that makes their life harder, and will stick with invalid HTML4 and Flash and Silverlight and all the other possibilities, which defeats the aim of improving interoperability on the web.
Also, browsers have bugs. What happens when a user tests in one browser which accidentally accepts their invalid code, without noticing that other browsers don't? (Possible answer: other browsers will have to start accepting that invalid code too, else their users will stop using that browser and start using the one that can actually display the web. And since the specification would only say how to handle valid code, the other browsers will have to reverse-engineer each other to get mostly-compatible behaviour for invalid code, which results in a mess of incompatibilities - that is what has happened for HTML4, and is what HTML5 is trying to fix by defining how all invalid content must be handled in a way that is sufficiently compatible with the existing behaviour (and existing bugs) of browsers.)
Also, most content is generated dynamically, so you can't simply test the page before you upload it. Server-side code has bugs, and draconian error handling does not make things easy to fix.
That is incorrect: the HTML5 parsing algorithm never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).
Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.
As well as Flash, you can do HTML and JavaScript and graphics in <canvas> – I experimented with an FPS engine a while ago, and developed it just with desktop versions of Opera and Firefox, and reportedly it actually works on the Wii too. (Recent nightly builds of Safari also support it – it's nice when browser interoperability works.)
It's quite horrifically inefficient doing all this in a web browser rather than C++, but there's still a lot you can manage that's within the bounds of feasibility, if you use some imagination to simplify what you need the technology to do for you.
Incidentally, I like the idea of supporting open standards like <canvas> and <video> rather than proprietary platforms like Flash, particularly given that everyone using the Wii browser has to (indirectly) pay for licensing the Flash player from Adobe.
The Database module is also reminiscent of the HTML5 Client-side database storage, which was added to the spec about a week ago. (Hmm, coincidence?)
The spec is currently very under-defined, but the intent is that some implementations (at least Firefox) will ship with it implemented using SQLite, and then people will start using it, so SQLite's dialect of SQL will become the de facto standard and everyone else has to implement it the same and then that will be specced.
Google Gears is using SQLite too, and the API is pretty similar, so it would be an interesting way to implement the HTML5 executeSql in older browsers.
You missed one:
5080711
x
5585366661 9936291260 7492046583 1594496864
6527018488 6376480100 5234631985 3288374753
×
2075818194 6442382764 5704813703 5946951629
3970800739 5209881208 3870379272 9090324679
3823431438 8414483488 2534053344 7691122230
2815832769 6525376091 4101891052 4199389933
4109711624 3589620659 7216748116 1749004803
6597355734 0925320542 5523689
= 2^1039-1
That isn't a problem. Apple and Microsoft (and Mozilla and Opera and others) are part of the W3C's new HTML Working Group, which is going to take the WHATWG's work (including canvas) and build on that (hopefully not by removing canvas in the process); and the W3C has a patent policy which means Apple's patent is not a problem, since they will follow that policy and make it freely usable by anyone implementing the specification. (The WHATWG doesn't have a patent policy, which is why Microsoft didn't get involved until it moved into the W3C.)
Yep, but the spec saying "3D would be cool" is a long way off actually doing any work on it - there was a bit of discussion on the mailing list some years ago, but (as far as I'm aware) nothing else has been done within the WHATWG since then. (And all the work is done in the open, so it would be obvious if they had done any.)
In any case, Microsoft is staying out of the WHATWG because of the lack of a patent policy, but they're involved in the HTML WG and seem to be interested in pursuing the HTML5 work now. I expect the 3D canvas work would be done in the WHATWG instead (as it seems much more productive than the HTML WG) and so Microsoft wouldn't be able to get involved even if they cared; but I expect that the 2D canvas will end up in the W3C spec, which will hopefully give Microsoft enough reason (and enough assurances about avoiding patent lawsuits) to implement it at some point in the future. But that'll probably be years in the best case, and 3D seems further out... In the meantime, I'll just keep making sites that work in everything except IE :-)
Only a minor point to clarify, but the WHATWG hasn't been working on the OpenGL API, and the 2D canvas (which it has worked on, and which has been implemented) isn't designed to be hardware-accelerated. Some Firefox and Opera developers have been experimenting with exposing OpenGL ES, and it seems likely that they will propose it in the WHATWG at some point to get standardisation, but that hasn't happened yet and it isn't much of a priority, and I expect it will take quite a while to get it sorted out.
(I've done some work with pseudo-3D in the 2D canvas, which is kind of slow, so I'm quite interested in how it's going to progress in the future.)
Would that be Rough Science? In particular, it sounds like the second series. I've seen a couple of the series over the past few years, and I believe it did a pretty good job of being a science show – the interest comes from watching people who actually know what they're doing, designing and building ingenious solutions (admittedly with very convenient tools and materials available) to problems that aren't inherently interesting (like making toothpaste or measuring the speed of a glacier), rather than relying on 'interesting' problems that are large/dangerous/explosive and lacking focus on the solution process.
Not quite valid – title is required. But I think the removal of the copy-and-paste doctype/meta strings (and script/style type, etc) is definitely nice for anyone writing pages by hand.
HTML4 says the default value for input's type is "text". Since HTML4 browsers don't recognise "email", they use the default instead, which gives a plain text box. (HTML4 is generally under-specified, so it doesn't actually say what should happen when a unrecognised value is given, but everybody implements it in the same way.)
You'll always have to do server-side validation – but users will have a nicer experience if errors are immediately flagged in a standard way by their web browser, rather than having to go through a slow round-trip to the server before being told they made a mistake. The browser can also provide some UI to let people quickly enter their own email address into the box, or to copy one from their address book.
That's not a relevant factor for the Safari developers to say "the HTML standards process has been moribund; the W3C's HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice" and "We declined to participate in the XHTML2 Working Group because we think XHTML2 is not an appropriate technology for the web". As far as I am aware, Mozilla, Opera and Microsoft are all not planning to ever implement XHTML2, whereas they are already working on HTML5 – HTML5 also has many features that are work-in-progress and which nobody is using yet, but which the browser vendors are already implementing, because they are valuable changes and don't break compatibility with the current hundred billion documents on the web.
A fundamental design principle of HTML5 is that HTML5 pages should work in existing browsers like IE6. You can write <input type="email">, and an HTML5 browser will allow useful auto-filling and immediate validation feedback, while old browsers will simply show a text box. New elements like <video> can have fallback content, e.g. to embed a Flash video player. New elements like <canvas> can be partially implemented by JavaScript in IE6. The HTML5 doctype (<!DOCTYPE HTML>) is chosen so that it triggers standards mode (as opposed to quirks mode) in all existing browsers.
So, you can write in HTML5 to provide added benefits for users of browsers that understand HTML5, while still being no worse than before for users of older browsers. And given that IE development has started up again, with IE7 making some progress on CSS standards compliance, and given that Microsoft is a member of the W3C's HTML working group which will almost certainly accept the current HTML5 work (as it was the reason for the working group to be formed, and nobody has raised any serious objections since it was proposed), I believe there is reason to be hopeful.
As it happens, that multipage version is one I hacked together yesterday, using the html5lib parser and an HTML5 innerHTML-like serialiser. The original and more-official version of the spec (from which the multipage one is derived) validates as HTML 4.01 Strict - the only problem is that it's quite large and makes browsers unhappy, hence the new multipage version.
(The multipage one does conform as HTML5 - but the conformance checker and the spec are still far from stable, so that doesn't mean a lot.)
Acid2 is only testing the error handling that is required by the standards – it is necessary that browsers support the error handling properly so that future standards can extend the language in a backward-compatible way. To a browser that was written to support CSS2, pages that use CSS3 will look like invalid nonsense; but since CSS defines the error handling, CSS3 can be designed so that it will fall back gracefully for users who only support CSS2 (and even CSS1), and it will be relatively painless to adopt the improvements. That's why it's important to specify and to test the error handling.
If you want Firefox with its original advantages and just its original features, why not use the original Firefox? Meanwhile, those who can benefit from the new technology will do so.
The only reason I can think of is that the old versions have unpatched security problems, so you'll want to upgrade after they're unsupported – but if you want the Firefox developers to stop adding new features, they're not going to still fix the security problems, they'll just move to more interesting and worthwhile projects and Firefox will die. Firefox has inertia now – and the whole web is gaining inertia, after stagnating during IE6's dominance, with even the W3C restarting realistic work on HTML – so it would be a waste if it didn't continue to grow and change.
In any case, they are planning to make future versions of Firefox faster and more secure and make the code less crufty, with better C++ usage and a better garbage collector to fix memory leaks and a new JavaScript VM. And Firefox is still only a 6MB download – it's not exactly the heaviest of programs you'll ever download.
VMware engineers also don't put any faith into being able to hide the fact that the guest OS is virtualised. When there are unavoidable holes like timing differences, there's no value in hiding some of the other avoidable holes.
But now they have an answer to the question "congratulations, you now know you're on a VMware Workstation 4.5 VM. What are you going to do about it?"
But qubits are a superposition of the two binary states – they're a|0> + b|1>, where |0> and |1> are linearly independent vectors in the state space, and a and b are complex numbers. I don't see why you couldn't have a third independent vector, giving qutits (?) of the form a|0> + b|1> + c|2>, and it probably doesn't even make the maths much harder; but binary qubits are easier to find in the physical world, such as the polarisation of photons.