Stuff like the printer driver creates a resident program (HP something) on the toolbar. Other applications after running only once, set itself to start at restart. WTF LOL!?. How is that possible? a OS sould ask user permission with something like sudo for setting apps to auto-run at restart.
If you install a program as root, that means the installer is running as root. That means it can do anything, including making something run at startup. It did ask for your permission to give the installer root privileges, when you started the program, and you gave it. (Maybe it's possible even for non-root processes to do this, but most programs are installed as root anyway, so it doesn't make a huge difference.)
This is a technicality, but it's fair enough. The other browsers should unprefix their implementations.
Until CSS3 is at least a recommendation rather than a draft, the CSS3-draft-related features remain proprietary extensions to CSS and the prefixes are appropriate.
In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.
Since the final standard does not exist yet, it is rather premature to remove prefixes on the assumption that the behavior (even if it matches the current draft) will match the final standard.
The features we're talking about, like border-radius, have reached Candidate Recommendation. According to informally-agreed-upon CSSWG process (see last sentence), prefixes can be dropped then. They don't have to wait until Recommendation – CSS 2.1 isn't even at REC, and won't reach it for some time. If IE has dropped a prefix after CR and another browser hasn't, it's fair to call that a standards-compliance win for IE.
Features specified in draft standards are not proprietary, in any case. And there is no "CSS3" standard: CSS 3 consists of a number of standards, which range from Proposed Recommendation (Selectors – further than CSS 2.1!) to not even written (like Math).
window.getSelection().toString() should give the same thing as Ctrl-C.
Now, if that means that they wanna mandate some weird way of toString() copying the character data that ignores the HTML markup and the CSS styles that apply to it, then Ctrl-C should behave in the same weird, stupid way. The whole purpose of the getSelection() method is to provide a programmatic way for a programmer to find out what would be copied if the user pressed Ctrl-C, and when they return different things it is fundamentally broken.
Agreed. And I've heard a complaint about this before. But it's the spec that's broken, not the test, and it's not Microsoft's fault either way.
It says “a copy of all the character data selected or partially selected by a Range”. By that description, and by any rational interpretation of the intent and usage of toString, window.getSelection().toString() should return the same thing that Ctrl-C returns as its plain text version (i.e. if you paste it into Notepad).
That's not true. It uses very precise terminology: character data is defined in XML to be "All text that is not markup". The DOM Level 1 spec explicitly refers to "character data" as being a term taken from XML. There is no newline in the markup and there is no newline in the DOM, so as the spec stands, there is no newline in the toString().
I mean, just look at what spec this is in: a DOM spec. The DOM specs don't depend on CSS at all. The references contain no mention of CSS. It is not possible to claim that the spec could possibly be read as saying CSS should affect the results of any operation it defines.
If the CSS creates an implicit line break character in the text node, I think that it should be copied as well.
This is a very sensible position, and I agree with it. I think it's what users will expect and it's the most useful. But it's not what the spec says. Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?
1st) Since HTML5 is still in a very early state, many browsers (AKA Webkit, Gecko, Presto) used prefixes for most tags and CSS properties. Example: round borders is -moz-border-radius in gecko, and -webkit-border-radius in Chrome. Some latest versions have taken some out of beta and also read border-radius, but most still don't. IE obviously uses border-radius, and that's why other's don't work.
This is a technicality, but it's fair enough. The other browsers should unprefix their implementations. In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.
2nd) The JS is tricky at best. Go and check it out. Lots of lines of code to perform a simple task, and those lines are carefully selected to fail in other browsers. I downloaded the tests, and they work on ALL browsers (I tested Chrome, Firefox and Opera, all on GNU/Linux, all on their latest version). That JS was crafted to fail on all browsers and work only on IE
Give examples and justification. From looking at the test names, at least some of them seem fair. For instance, the tests of SVG in text/html fail in non-IE9 browsers because in fact, no other tested browser implements that feature. That's legitimate.
3rd) I took the time to run the source of many of their scripts through the W3C validator. Most scripts have several warnings, some errors, etc. They DO NOT VALIDATE.
This is totally irrelevant to the tests' legitimacy, unless you can point to an actual case where it causes an incorrect failure.
4th) The tests aren't really HTML5. Only the HTML5 tests are actual HTML5, the others are XHTML 1.0 strict... except they are not, because they use HTML5 styles and tags, and they do not validate. Validator says: The document located at was tentatively checked as XHTML 1.0 Strict. This means that with the use of some fallback or override mechanism, we successfully performed a formal validation using an SGML, HTML5 and/or XML Parser(s). In other words, the document would validate as XHTML 1.0 Strict if you changed the markup to match the changes we have performed automatically, but it will not be valid until you make these changes.
It makes no difference. HTML5 and CSS define processing for documents regardless of doctype or validation status. Indeed, you want some tests that are deliberately invalid, to test error handling.
In summary, there may be legitimate objections to the test (obviously including selective coverage), but you haven't made them.
They create a new <div> element and insert it at the end of the selection in an existing <div>. In other words, they generate this:
<div id="div1">some text<div>new text</div></div>
...then they check to see if the value returned by selection.toString() is equal to “some textnew text”.
Morons. It shows up as this:
some text
new text
...and that’s what toString() gives you, too.
The test is right per the spec text, the behavior of Gecko and WebKit is wrong. Opera is also right here. Read the definition of toString(). It says, "This does nothing more than simply concatenate all the character data selected by the Range. This includes character data in both Text and CDATASection nodes." In the example you give, there is no actual newline character in any text node – the line break is inserted by CSS.
Now, maybe the Gecko and WebKit behavior makes more sense. But it's not what the spec says.
There isn't full agreement but most of it is pretty complete. The only non nitpicking issue that people cant agree on is video/audio. Microsoft and Apple want push h.264 into their browsers and push h.264 as a de-facto standard so they advocate against defining a codec in HTML5 (an open standard). Of course they dont support anything else in IE and Safari(for HTML5 video tags)
If you think audio and video codecs are the only part of the spec that's controversial, you clearly don't follow the HTMLWG mailing list. There are 29 open issues, and many of them have been hotly debated. So have lots of other issues that weren't formally raised to the tracker.
The video codec issue actually was resolved long ago – the spec just doesn't say what codecs are required, and no one is really objecting to that. Mozilla, Opera, and Google support open codecs, but none has suggested that they actually be required by the spec when other major browsers refuse to implement them.
Mod parent up. That test looks pretty decent, although it has some issues. For instance, testing for device element when it's not fully specced; testing WebSQL when that's moribund; and testing WebSocket when it's not stable. My results are:
Chrome: 212/300 + 6 bonus (dev channel)
Firefox: 171/300 + 6 bonus (nightly)
Opera: 129/300 + 5 bonus (10.60 preview)
IE: 32/300 + 1 bonus (latest Platform Preview)
'Nuff said. The detailed results look legitimate to me, as these things go.
That estimates the spec will not be completely finished (which means test cases and interoperable implementations for every single feature) until 2022 or later. But there are large parts that are uncontroversial and interoperably implemented now, like canvas, the text/html syntax, drag-and-drop, getElementsByClassName(), etc. It's a huge spec, it's not going to reach agreement all at once.
But a test of all specifications of the HTML5 Working Draft is not something easy. Have we ever had a test of all specifications of even CSS 2.1?
Not yet, but it's being worked on. As CSS 2.1 says, "A test suite and an implementations report will be provided before the document becomes a Proposed Recommendation." Microsoft has contributed an enormous number of tests to the CSS 2.1 suite.
OK, can we have a test that includes all specifications of the HTML5 Working Draft?
Yes, we will. HTML5 will have an official test suite. It will take a very long time to put it together, though, since the spec is hundreds of pages long, and writing tests isn't trivial. You have to carefully read the spec and fully understand it, for one, which requires a lot of time and skill. Microsoft is helping by contributing tests for features they implement.
I do, and I strongly recommend that everyone else do too. But as a web developer, I'm enthusiastic about better IE standards support anyway, because I know that many of my users use IE regardless of what I do. If it's more standards-compliant, my job is that much easier.
what have they exactly improved with interop? I've never seen them any different than normal, aka zero interop unless mandated by courts.
IE8 is as fully CSS2.1-compliant as any browser. You no longer need to write separate stylesheets for IE8 in practice, you just have to make sure not to use CSS3 features (it only implements a couple). IE9 improves standards compliance in a host of ways. None of this is court-mandated, it's probably just Microsoft realizing that they'd like web developers not to loathe them with the fury of a thousand blazing suns.
Read your own link, please, in full. The editor estimates that HTML5 will not reach Recommendation status at the W3C until 2022 or later. This is not "being a standard". HTML5 is a draft standard right now de jure, and much of it is a de facto standard as well. Browsers are already implementing it and it can already be used, regardless of its progress along the formal W3C recommendation track. The latter is a formality and can be safely ignored if you're not a bureaucrat.
Well, that's the problem with HTML. The W3C doesn't create an acceptance test, so there's really no objective way to measure how compliant a particular browser truly is.
An official test suite will be developed for HTML5. It's a huge amount of work, though. Microsoft is contributing tests as they add features to IE9, which is great. Of course they pass all the tests; they're probably designing the tests as part of their implementation, as part of an automated test suite for IE9. But it's great that they're helping out by contributing their internal tests to the public for use in a comprehensive cross-browser test suite.
The only obnoxious thing here is that they're posting charts that make it look like they pass everything and other browsers fail, when the test suite is not representative at all. Also, the test page uses stable releases of other browsers, and alphas of IE9. If they used recent Firefox trunk, for example, many of the "HTML5 foreign content" tests would pass – that was recently enabled by default (it was hidden behind html5.enable in about:config in 3.6).
But there will certainly be an official W3C test suite, and Microsoft's tests will probably form a valuable part of it.
Cinema tickets still sell even though everyone is torrenting movies.
Pay actors 5 digit wages instead of 7 digit wages.
TA-DA!
I'm pretty sure that seven-digit wages for actors is the least of the movie studios' problems. The special effects, sets, extras, etc. all must cost a lot more in the end, no? Not to mention, movie studios colluding to fix actors' salaries at below market rates sounds like a violation of antitrust law to me.
True, until game-manufacturers come up with Chrome-compatible games and other software companies make chrome-compatible applications?
Already, Office exists by Google too... and creating a replacement for minesweeper really isn't that difficult.
Chrome apps are web apps. That's an explicit design goal, last I checked (admittedly I haven't kept up). Everything that works on Chrome OS will work on the Chrome browser on any other OS, so no one will ever use Chrome OS solely because of the apps.
I think the number one reason for not going to HTML5 is MSIE. Microsoft has no intention of creating a fully standards compliant browser. If they did that, they would likely also need to make their web based applications standards compliant and that would end their lock-in for Windows on the desktop and server where web applications are concerned.
This simply hasn't been the case since IE7. IE8 is fully CSS2.1-compliant, which removes most of the pain of dealing with IE already. IE9 adds many CSS3 features and also has a far more compatible JavaScript implementation. Microsoft's explicit goal for IE9 is that developers should be able to use the same markup as much as possible. IE8 was an enormous improvement, and the IE9 previews look like they'll also be far better. The only problem is IE users who don't upgrade.
Re-create Badgers in Flash. Once you can do that without adding more than 50% to the file size, and you can provide a write-up about the tools you used, only then will HTML5 be ready for prime time.
You're attacking a straw man. HTML5 will not be able to completely replace Flash for at least, say, five years. No one denies that. The reason HTML5 will win in the end is because of the advantages of competing implementations in several browsers vs. implementation in a single closed binary. Even if Flash always has more features than HTML5, it won't help if HTML5 is faster, more stable, and installed by default. All the major OS and browser vendors hate Flash and are happy to make it scary or difficult to install Flash – or impossible, in the case of the iPhone. HTML5 will work out of the box within a few years, and have feature parity for practical purposes.
Yes, authoring tools are a problem. But if that's the only long-term advantage Flash has, then it's in Adobe's interest to simply support HTML5 as an output format for all their tools. They don't make money off selling the Flash player; they'll adapt their tools to whatever the best output format is.
HTML5 will win. First bit by bit, then more rapidly as Flash's market share becomes lower. I'm going to predict, for the record, that Flash will be clearly moribund in less than five years, used almost exclusively on unmaintained sites and (maybe, for some simple things) as a fallback for old browsers.
You mean, end all security updates for an operating system that they've committed in writing to support until 2014? When businesses have planned their upgrade schedules around XP's announced EOL, and aren't done testing a switch to newer OSes, or have calculated that they don't need to switch yet? So Microsoft basically leaves them overnight with an OS that's not going to be supported for as long as it will take them to switch to a new one?
Not only would that be an absolutely awful business decision, I wouldn't be surprised if it's illegal. Businesses and individuals purchased XP with Microsoft's assurance that it would be supported. Selling a product and then not keeping to your claims is false advertising, or fraud.
html 5 is screwed from the start because it isn't xhtml2.
If I was to design the future of the web, it would be xhtml2 with css3.
Thing is, people tried that, and it failed horribly. HTML5 is actually working, because it emphasizes compatibility. If you want to live in your utopian pipe dream and throw out everything to start from scratch instead of hacking on top of the mess we're stuck with, have fun, but the proof is in the pudding. XHTML2 died, HTML5 has won.
Maybe it's because browser implementers are evil and not forward-thinking enough, but guess what? Step one to a successful standard is get implemented. No browser implementer bothered implementing XHTML2, and the authors apparently didn't care. It was dead before it started.
You have a funny definition of "screwed" if you think HTML5 is screwed and XHTML2 is not, I've got to say.
Plus simple site based local storage (cookies that don't always get transmitted to the server would do if the storage size policy was a little less strict)
Like HTML5's localStorage, which has been implemented in all browsers (even IE8)?
the ability to transfer part of a model to the next page on submit without making a round trip to the server
I'm not sure what you mean, but this sounds like AJAX.
and throw in some canvas/audio/video tags for everyone else enjoy.
Which were introduced by HTML5, and which were conspicuously absent from XHTML2.
So, I'm violating my usual rule of not responding to ACs, only because you're such an idiot (which conveniently explains why you are posting AC).
"perfect" in that they will distribute the writes 100% evenly across all available spare sectors
See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word.
So, fill up 75% of your SSD with files which don't change, then beat up on the remaining sectors 4 times as much as truly evenly distributed writes would cause.
It's not clear what you "MLC" comment was about, since I specifically mentioned that as an example of flash technology.
So keep track of how many times each erase block has been written, and if some blocks get erased too often relative to the rest, move data from the least-erased blocks onto the most-erased blocks. You do a few extra writes this way, but a negligible number if you set the thresholds high enough. And then you'll get fully leveled writes. I'm sure the clever folks at places like Intel have figured out strategies like this (although for the cheap stuff, who knows).
Slashdot Mirror
Stuff like the printer driver creates a resident program (HP something) on the toolbar. Other applications after running only once, set itself to start at restart. WTF LOL!?. How is that possible? a OS sould ask user permission with something like sudo for setting apps to auto-run at restart.
If you install a program as root, that means the installer is running as root. That means it can do anything, including making something run at startup. It did ask for your permission to give the installer root privileges, when you started the program, and you gave it. (Maybe it's possible even for non-root processes to do this, but most programs are installed as root anyway, so it doesn't make a huge difference.)
Until CSS3 is at least a recommendation rather than a draft, the CSS3-draft-related features remain proprietary extensions to CSS and the prefixes are appropriate.
Since the final standard does not exist yet, it is rather premature to remove prefixes on the assumption that the behavior (even if it matches the current draft) will match the final standard.
The features we're talking about, like border-radius, have reached Candidate Recommendation. According to informally-agreed-upon CSSWG process (see last sentence), prefixes can be dropped then. They don't have to wait until Recommendation – CSS 2.1 isn't even at REC, and won't reach it for some time. If IE has dropped a prefix after CR and another browser hasn't, it's fair to call that a standards-compliance win for IE.
Features specified in draft standards are not proprietary, in any case. And there is no "CSS3" standard: CSS 3 consists of a number of standards, which range from Proposed Recommendation (Selectors – further than CSS 2.1!) to not even written (like Math).
window.getSelection().toString() should give the same thing as Ctrl-C.
Now, if that means that they wanna mandate some weird way of toString() copying the character data that ignores the HTML markup and the CSS styles that apply to it, then Ctrl-C should behave in the same weird, stupid way. The whole purpose of the getSelection() method is to provide a programmatic way for a programmer to find out what would be copied if the user pressed Ctrl-C, and when they return different things it is fundamentally broken.
Agreed. And I've heard a complaint about this before. But it's the spec that's broken, not the test, and it's not Microsoft's fault either way.
Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?
This should say "tests" instead of "text", obviously.
It says “a copy of all the character data selected or partially selected by a Range”. By that description, and by any rational interpretation of the intent and usage of toString, window.getSelection().toString() should return the same thing that Ctrl-C returns as its plain text version (i.e. if you paste it into Notepad).
That's not true. It uses very precise terminology: character data is defined in XML to be "All text that is not markup". The DOM Level 1 spec explicitly refers to "character data" as being a term taken from XML. There is no newline in the markup and there is no newline in the DOM, so as the spec stands, there is no newline in the toString().
I mean, just look at what spec this is in: a DOM spec. The DOM specs don't depend on CSS at all. The references contain no mention of CSS. It is not possible to claim that the spec could possibly be read as saying CSS should affect the results of any operation it defines.
If the CSS creates an implicit line break character in the text node, I think that it should be copied as well.
This is a very sensible position, and I agree with it. I think it's what users will expect and it's the most useful. But it's not what the spec says. Surely you're not blaming Microsoft for writing text according to the spec itself rather than what they think the spec should say?
1st) Since HTML5 is still in a very early state, many browsers (AKA Webkit, Gecko, Presto) used prefixes for most tags and CSS properties. Example: round borders is -moz-border-radius in gecko, and -webkit-border-radius in Chrome. Some latest versions have taken some out of beta and also read border-radius, but most still don't. IE obviously uses border-radius, and that's why other's don't work.
This is a technicality, but it's fair enough. The other browsers should unprefix their implementations. In some cases, they may be using prefixes because their prefixed versions actually behave differently from the final standard.
2nd) The JS is tricky at best. Go and check it out. Lots of lines of code to perform a simple task, and those lines are carefully selected to fail in other browsers. I downloaded the tests, and they work on ALL browsers (I tested Chrome, Firefox and Opera, all on GNU/Linux, all on their latest version). That JS was crafted to fail on all browsers and work only on IE
Give examples and justification. From looking at the test names, at least some of them seem fair. For instance, the tests of SVG in text/html fail in non-IE9 browsers because in fact, no other tested browser implements that feature. That's legitimate.
3rd) I took the time to run the source of many of their scripts through the W3C validator. Most scripts have several warnings, some errors, etc. They DO NOT VALIDATE.
This is totally irrelevant to the tests' legitimacy, unless you can point to an actual case where it causes an incorrect failure.
4th) The tests aren't really HTML5. Only the HTML5 tests are actual HTML5, the others are XHTML 1.0 strict ... except they are not, because they use HTML5 styles and tags, and they do not validate. Validator says: The document located at was tentatively checked as XHTML 1.0 Strict. This means that with the use of some fallback or override mechanism, we successfully performed a formal validation using an SGML, HTML5 and/or XML Parser(s). In other words, the document would validate as XHTML 1.0 Strict if you changed the markup to match the changes we have performed automatically, but it will not be valid until you make these changes.
It makes no difference. HTML5 and CSS define processing for documents regardless of doctype or validation status. Indeed, you want some tests that are deliberately invalid, to test error handling.
In summary, there may be legitimate objections to the test (obviously including selective coverage), but you haven't made them.
The Insert Node Into Selection test is equally retarded.
They create a new <div> element and insert it at the end of the selection in an existing <div>. In other words, they generate this:
...then they check to see if the value returned by selection.toString() is equal to “some textnew text”.
Morons. It shows up as this:
...and that’s what toString() gives you, too.
The test is right per the spec text, the behavior of Gecko and WebKit is wrong. Opera is also right here. Read the definition of toString(). It says, "This does nothing more than simply concatenate all the character data selected by the Range. This includes character data in both Text and CDATASection nodes." In the example you give, there is no actual newline character in any text node – the line break is inserted by CSS.
Now, maybe the Gecko and WebKit behavior makes more sense. But it's not what the spec says.
There isn't full agreement but most of it is pretty complete. The only non nitpicking issue that people cant agree on is video/audio. Microsoft and Apple want push h.264 into their browsers and push h.264 as a de-facto standard so they advocate against defining a codec in HTML5 (an open standard). Of course they dont support anything else in IE and Safari(for HTML5 video tags)
If you think audio and video codecs are the only part of the spec that's controversial, you clearly don't follow the HTMLWG mailing list. There are 29 open issues, and many of them have been hotly debated. So have lots of other issues that weren't formally raised to the tracker.
The video codec issue actually was resolved long ago – the spec just doesn't say what codecs are required, and no one is really objecting to that. Mozilla, Opera, and Google support open codecs, but none has suggested that they actually be required by the spec when other major browsers refuse to implement them.
The beta version seems to test more of the spec: http://beta.html5test.com/
Mod parent up. That test looks pretty decent, although it has some issues. For instance, testing for device element when it's not fully specced; testing WebSQL when that's moribund; and testing WebSocket when it's not stable. My results are:
'Nuff said. The detailed results look legitimate to me, as these things go.
http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F
That estimates the spec will not be completely finished (which means test cases and interoperable implementations for every single feature) until 2022 or later. But there are large parts that are uncontroversial and interoperably implemented now, like canvas, the text/html syntax, drag-and-drop, getElementsByClassName(), etc. It's a huge spec, it's not going to reach agreement all at once.
But a test of all specifications of the HTML5 Working Draft is not something easy. Have we ever had a test of all specifications of even CSS 2.1?
Not yet, but it's being worked on. As CSS 2.1 says, "A test suite and an implementations report will be provided before the document becomes a Proposed Recommendation." Microsoft has contributed an enormous number of tests to the CSS 2.1 suite.
OK, can we have a test that includes all specifications of the HTML5 Working Draft?
Yes, we will. HTML5 will have an official test suite. It will take a very long time to put it together, though, since the spec is hundreds of pages long, and writing tests isn't trivial. You have to carefully read the spec and fully understand it, for one, which requires a lot of time and skill. Microsoft is helping by contributing tests for features they implement.
Code to standards. Let the poor browsers fail.
So you get fired? Great advice.
Here's a thought... USE ANOTHER BROWSER.
I do, and I strongly recommend that everyone else do too. But as a web developer, I'm enthusiastic about better IE standards support anyway, because I know that many of my users use IE regardless of what I do. If it's more standards-compliant, my job is that much easier.
what have they exactly improved with interop? I've never seen them any different than normal, aka zero interop unless mandated by courts.
IE8 is as fully CSS2.1-compliant as any browser. You no longer need to write separate stylesheets for IE8 in practice, you just have to make sure not to use CSS3 features (it only implements a couple). IE9 improves standards compliance in a host of ways. None of this is court-mandated, it's probably just Microsoft realizing that they'd like web developers not to loathe them with the fury of a thousand blazing suns.
HTML 5 won't be a standard until 2020. Or it looks like they've removed that wildly pessimistic estimate now: http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F.
Read your own link, please, in full. The editor estimates that HTML5 will not reach Recommendation status at the W3C until 2022 or later. This is not "being a standard". HTML5 is a draft standard right now de jure, and much of it is a de facto standard as well. Browsers are already implementing it and it can already be used, regardless of its progress along the formal W3C recommendation track. The latter is a formality and can be safely ignored if you're not a bureaucrat.
Well, that's the problem with HTML. The W3C doesn't create an acceptance test, so there's really no objective way to measure how compliant a particular browser truly is.
An official test suite will be developed for HTML5. It's a huge amount of work, though. Microsoft is contributing tests as they add features to IE9, which is great. Of course they pass all the tests; they're probably designing the tests as part of their implementation, as part of an automated test suite for IE9. But it's great that they're helping out by contributing their internal tests to the public for use in a comprehensive cross-browser test suite.
The only obnoxious thing here is that they're posting charts that make it look like they pass everything and other browsers fail, when the test suite is not representative at all. Also, the test page uses stable releases of other browsers, and alphas of IE9. If they used recent Firefox trunk, for example, many of the "HTML5 foreign content" tests would pass – that was recently enabled by default (it was hidden behind html5.enable in about:config in 3.6).
But there will certainly be an official W3C test suite, and Microsoft's tests will probably form a valuable part of it.
TA-DA!
I'm pretty sure that seven-digit wages for actors is the least of the movie studios' problems. The special effects, sets, extras, etc. all must cost a lot more in the end, no? Not to mention, movie studios colluding to fix actors' salaries at below market rates sounds like a violation of antitrust law to me.
True, until game-manufacturers come up with Chrome-compatible games and other software companies make chrome-compatible applications? Already, Office exists by Google too... and creating a replacement for minesweeper really isn't that difficult.
Chrome apps are web apps. That's an explicit design goal, last I checked (admittedly I haven't kept up). Everything that works on Chrome OS will work on the Chrome browser on any other OS, so no one will ever use Chrome OS solely because of the apps.
I think the number one reason for not going to HTML5 is MSIE. Microsoft has no intention of creating a fully standards compliant browser. If they did that, they would likely also need to make their web based applications standards compliant and that would end their lock-in for Windows on the desktop and server where web applications are concerned.
This simply hasn't been the case since IE7. IE8 is fully CSS2.1-compliant, which removes most of the pain of dealing with IE already. IE9 adds many CSS3 features and also has a far more compatible JavaScript implementation. Microsoft's explicit goal for IE9 is that developers should be able to use the same markup as much as possible. IE8 was an enormous improvement, and the IE9 previews look like they'll also be far better. The only problem is IE users who don't upgrade.
Re-create Badgers in Flash. Once you can do that without adding more than 50% to the file size, and you can provide a write-up about the tools you used, only then will HTML5 be ready for prime time.
You're attacking a straw man. HTML5 will not be able to completely replace Flash for at least, say, five years. No one denies that. The reason HTML5 will win in the end is because of the advantages of competing implementations in several browsers vs. implementation in a single closed binary. Even if Flash always has more features than HTML5, it won't help if HTML5 is faster, more stable, and installed by default. All the major OS and browser vendors hate Flash and are happy to make it scary or difficult to install Flash – or impossible, in the case of the iPhone. HTML5 will work out of the box within a few years, and have feature parity for practical purposes.
Yes, authoring tools are a problem. But if that's the only long-term advantage Flash has, then it's in Adobe's interest to simply support HTML5 as an output format for all their tools. They don't make money off selling the Flash player; they'll adapt their tools to whatever the best output format is.
HTML5 will win. First bit by bit, then more rapidly as Flash's market share becomes lower. I'm going to predict, for the record, that Flash will be clearly moribund in less than five years, used almost exclusively on unmaintained sites and (maybe, for some simple things) as a fallback for old browsers.
Also, XP is ten years old. What version of Firefox will installs on Debian Potato/Woody?
No successor to XP was released until three and a half years ago. And no halfway-decent successor was released until less than a year ago.
To kill IE6, kill XP. Here's how.
1. End all security updates for XP.
You mean, end all security updates for an operating system that they've committed in writing to support until 2014? When businesses have planned their upgrade schedules around XP's announced EOL, and aren't done testing a switch to newer OSes, or have calculated that they don't need to switch yet? So Microsoft basically leaves them overnight with an OS that's not going to be supported for as long as it will take them to switch to a new one?
Not only would that be an absolutely awful business decision, I wouldn't be surprised if it's illegal. Businesses and individuals purchased XP with Microsoft's assurance that it would be supported. Selling a product and then not keeping to your claims is false advertising, or fraud.
html 5 is screwed from the start because it isn't xhtml2.
If I was to design the future of the web, it would be xhtml2 with css3.
Thing is, people tried that, and it failed horribly. HTML5 is actually working, because it emphasizes compatibility. If you want to live in your utopian pipe dream and throw out everything to start from scratch instead of hacking on top of the mess we're stuck with, have fun, but the proof is in the pudding. XHTML2 died, HTML5 has won.
Maybe it's because browser implementers are evil and not forward-thinking enough, but guess what? Step one to a successful standard is get implemented. No browser implementer bothered implementing XHTML2, and the authors apparently didn't care. It was dead before it started.
You have a funny definition of "screwed" if you think HTML5 is screwed and XHTML2 is not, I've got to say.
Plus simple site based local storage (cookies that don't always get transmitted to the server would do if the storage size policy was a little less strict)
Like HTML5's localStorage, which has been implemented in all browsers (even IE8)?
the ability to transfer part of a model to the next page on submit without making a round trip to the server
I'm not sure what you mean, but this sounds like AJAX.
and throw in some canvas/audio/video tags for everyone else enjoy.
Which were introduced by HTML5, and which were conspicuously absent from XHTML2.
So, I'm violating my usual rule of not responding to ACs, only because you're such an idiot (which conveniently explains why you are posting AC).
See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word. So, fill up 75% of your SSD with files which don't change, then beat up on the remaining sectors 4 times as much as truly evenly distributed writes would cause. It's not clear what you "MLC" comment was about, since I specifically mentioned that as an example of flash technology.
So keep track of how many times each erase block has been written, and if some blocks get erased too often relative to the rest, move data from the least-erased blocks onto the most-erased blocks. You do a few extra writes this way, but a negligible number if you set the thresholds high enough. And then you'll get fully leveled writes. I'm sure the clever folks at places like Intel have figured out strategies like this (although for the cheap stuff, who knows).