This isn't a "non-story." Compliance with web standards is an important feature for a modern web browser.
Yes, it is an important feature. But no new information is being offered here. It's repeating old information to clear up confusion caused by Slashdot reposting an article from last year.
The headline is also not misleading, as Wilson states they're between 50% and 90% compliant with CSS 2.1.
Compliance is not a matter of degree. By pointing out that they haven't even implemented 90% of the specification, he's stating that Internet Explorer is not compliant. The opposite of what is claimed in the headline.
No. Not even close. Throw away the idea that he's arguing that Internet Explorer 7 is standards compliant. It's a complete fabrication; he never claimed that.
What he is saying is that they've done a lot of work in the area of standards compliance, there are moderate improvements, and that it doesn't really make sense to say that it supports 57.324% of the specification or whatever kind of number you can come up with, because there's really no sensible way of measuring something like that objectively.
Chris Wilson isn't a marketer, either. He's worked on Internet Explorer for years, he was on the W3C CSS working group and has his name in the acknowledgements of the specifications. I believe him when he claims to be working hard to bring Internet Explorer into compliance, but there's only so much a person can do without support from above.
Read what you quoted again. He's not saying that they don't have testcases, what he's saying is that you can't objectively quantify how far they have to go.
Please quote properly. The full quote is "there isn't an official test suite that exhaustively tests whether you comply with the standard or not." And that is true. A test suite cannot tell you if an implementation is compliant or to what degree an implementation is compliant. It can only point out particular things that are broken. If you're thinking of dividing the number of passed tests over the number of total tests, that still won't tell you how compliant an implementation is because it will be weighted according to the number of test cases for each particular language feature. If you weight them differently, then you let your own opinions about what is important into the analysis, which is why he followed up with "And any analysis you can do is going to be somewhat biased."
What a ridiculous, misleading title. Microsoft have claimed nothing of the sort. They've claimed improvements, which is true. In fact, the article quotes Chris Wilson as saying he thinks they've implemented over half of the CSS 2.1 specification, but not 90%. That's hardly insisting it is compliant, is it?
I'm definitely no Internet Explorer fan - I think Microsoft's efforts with Internet Explorer 7 have been abysmal. But this is a non-story. Everybody knows that Internet Explorer isn't compliant. Everybody who has been paying attention knows that there have been gradual but long-demanded improvements included in Internet Explorer 7.
Shame on you Taco for posting a story with such a dishonest, inflammatory headline. If this were a political website, the equivalent to what you just did would be a Democrat posting a story saying "Dubya eats babies!"
As I was saying elsewhere, the UK has a history of passing stupid laws, and then having the rest of the country ignore or bypass them.
For example, we have a law saying that all schools must provide daily worship of a predominantly Christian nature. Over three-quarters of schools in the country are simply breaking the law or finding loopholes. As a result, the law is being relaxed, and will probably be disposed of entirely before long.
If you are approaching this from an American perspective, where bad laws like the DMCA are routinely enforced, then I can see how this might be considered an absolute disaster in terms of liberty. But from a British perspective, it's just another law to be ignored, and if anybody tries to use it, there'll be an uproar. As things stand, it hasn't even been used and there's already a backlash that has reached the House of Lords.
Actually, since the House of Lords don't have to chase after votes all the time, they help chuck out all the stupid knee-jerk laws the House of Commons come up with to make it look like they are doing something important. It's a useful component of a democratic system that mitigates one of the downsides of democracy - that the elected representatives are concerned with appearances more than the well-being of the country.
The university book store is a business just like any other. Their only interest is in making money.
Yes, but the bookshop isn't earning all the money students are paying for Microsoft Office, their markup is relatively small. I expect it would be more profitable to sell OpenOffice CDs at half the price of Microsoft Office because it only costs the price of a blank CD to restock.
Predictably, all open source offerings are blown away by Internet Explorer and Microsoft Office's 100% deployment rates.
Okay, it was back in the 90s, but when I was at uni, there were plenty of UNIX workstations that didn't have either of those installed. I can't imagine things have changed so drastically in the last few years or that I went to the only university that used UNIX.
For a machine to detect explosives in liquid or solid form, it bombards an object with energy -- such as radio waves or neutrons -- and in seconds measures the reaction
The plan is that the baby that drinks the neutron-laced super-milk will turn into some sort of terrorist-fighting mega-baby with superpowers. That's how the machine helps in the War on Terra!
How are the slashdot editors supposed to know which sites have limited bandwidth?
They could email and ask? When you can take small websites completely offline with the amount of traffic Slashdot gets, it's irresponsible to not give any warning or caching, especially when your excuse is that you just can't wait six hours for this "cool breaking story". Hands up everybody who just couldn't wait another six hours to see Star Trek posters?
Or, if you want the techie approach, something similar to robots.txt would be simple for high-traffic websites like Slashdot to respect.
You obviously missed my point. Please show me somebody who thinks it is necessary to protect GPLed software written 43 years ago, by somebody who's made more than enough money to retire on and who died decades ago.
Examples of the compositions infringed include "Beautiful Day" written by Clayton/Evans/Mullen/Hewson and administered by Universal Music Publishing, and "I Want To Hold Your Hand" written by Lennon/McCarthy and administered by Sony/ATV Tunes LLC.
Isn't it awful? If people keep infringing his copyrights, John Lennon might have to quit music and get a day job! Then where will all the Beatles fans be? They'll be moaning about how they aren't getting any new Beatles music, I'm sure.
1. Makes it unreadable for the blind or anyone else using a browser that doesn't use a fancy javascript.
Ajax is no different to any other kind of JavaScript - if you know what you are doing, there's no reason it should cause problems for the blind or people without JavaScript. You have formed this opinion because lots of people who don't know what they are doing are using Ajax, not because Ajax inherently has this problem.
2. Makes it less readable or unreadable to google and yahoo search engines.
Again, Ajax is like any other JavaScript in this respect. If you know what you are doing, this isn't a problem.
3. Adds yet another step in the web development pipeline
Well yes, in general, if you want to add features, you have to add development time. This is to be expected.
4. Further supports M$'s "we'll make our own javascript" cause. IE handles AJAX differently then the rest ( big surprise ).
You have that backwards. Internet Explorer handles Ajax differently because it provided the XMLHttpRequest object first. When the other browsers copied it, they implemented it differently.
In actual fact, the differences are trivial. It's a few lines of generic code to make Internet Explorer act like the other browsers. And Microsoft, rather than encouraging the different interfaces, is actually changing Internet Explorer 7 to work like the other browsers.
5. Breaks the standard accepted policy of unified pages ( essentially re-introducing frames )
Web pages haven't been unified since <img> was introduced in Mosaic. What you are concerned with is addressability, another thing in which poor coders are giving a false impression.
AJAX yappers talk about response and app like look and feel. If you encounter one of these people then rest assured that they don't know what good layout design and CSS are!
Utter nonsense. In fact, I'd say the opposite is true. If you are concerned with look and feel, then good layout design is what you are striving for, and CSS is the way that you achieve it.
With proper layout and CSS you can make a web site or application respond and look just like an Ajax one without having to use Ajax or code up some JavaScript piping.
This is simply not true. You can make all the same features work, but they don't work as well, and certainly don't respond as quickly.
The browser will cache the layout correctly and thus the extra 3k of information that AJAX supporters say they avoid is in fact already avoided.
When web developers talk about the layout being cached, they mean the stylesheets that define the layout. Things like sidebars, headers, menus etc aren't cached themselves, they still appear in the HTML as content. It's just how they look, as defined in CSS, that is cached. You aren't avoiding downloading all of that superfluous information when you cache a stylesheet, you still have to download the content. Ajax avoids that.
Google and their employees are super smart- Maybe if you look at their source code you can capture some of their magic
Please don't. Google are good at server-side stuff, good at user-interfaces, and good at picking out the best mix of unusual features. They suck at client-side web development. GMail is great, yes, but that's because of the features and because they chose to use XMLHttpRequest - not because of the actual quality of their code. If you learn from Google's code, you'll learn wrong. IBM had a good series of tutorials on Ajax, and the DOM Scripting book is reputed to be very good. I suggest you learn from those instead.
The content loaded by AJAX can't be indexed by search engines.
That depends on how it's implemented. The best way of using JavaScript is to store the information it needs within the structure HTML provides. That way, anything that can parse HTML - including search engines - can easily extract the information.
For example, if you're building a photo gallery that uses Ajax to dynamically load information about the photograph from the server, you can use a normal HTML link or the <img> element's longdesc attribute to provide the URI to the extra information.
Just because Ajax uses JavaScript, it doesn't mean that you need to start ignoring HTML. If you use JavaScript properly, your Ajax content will still usually be indexed.
Flash is far more robust and elegant than the slashdot crowd gives it credit for being.
As an application development platform? Sure, why not. As a web application development platform? No chance.
The fundamental problem with Flash is the same as it ever was. You have a presentation format that wraps up presentation, scripting and content into one binary bundle that couples everything together so tightly it's impossible to decompose. You might as well stick a Powerpoint presentation on the web. Virtually all of Flash's other problems that people complain about are merely symptoms of this one underlying design flaw.
With a normal web application, you can do all kinds of things with the various pieces. On a slow connection? Turn off the graphics. Indexing content? Just parse the HTML. Security worries? Switch off scripting. Hate the design? Use a user stylesheet. Missing a feature? Add it with Greasemonkey. Concerned with a particular part of the web application? Link directly to it.
Flash either makes these things impossible or way more difficult than they should be because everything is tightly coupled instead of loosely coupled the way all the other web technologies are. By itself, this single factor limits interoperability, which is the whole basis for the WWW's strength. Sure, you might be able to produce a fancy interface, but you're doing it at the expense of cutting off ties to the rest of the web's technologies. It's Flash's fundamental design flaw that Adobe/Macromedia don't seem to understand or care about fixing.
Ajax, on the other hand, works with all the other WWW technologies. It doesn't invent its own way of representing content, it uses HTML. It doesn't have its own layout system, it uses CSS. Its constituent components already all exist, and, more importantly, lots of other software is built to manipulate them.
For example, if I have my browser set up to automatically make tables sortable, this works with tables in an Ajax application because Ajax applications would just use a normal, standard HTML table. The same thing hasn't got a chance of working in Flash because it doesn't build on top of existing technologies, it throws them all away and does its own thing.
Flash isn't a way of creating web applications. It's a way of creating traditional applications and making them appear in a browser window. If that's what you want, then fine, go ahead and do that. But don't pretend they are web applications, because they've thrown away everything that makes the web so powerful and replaced it with something else.
The table leg was wrapped in a bag and police had been told he had a shotgun. If you're suspected of being a terrorist, having a flourescent water gun isn't going to make the slightest bit of difference. And you fail to mention that the guy "armed with a lighter" was holding a lighter that was an imitation gun. It's a bit dishonest not to mention this crucial fact and fail to link the article properly so most Slashdotters won't bother reading the article, don't you think?
Yes, all of these were regrettable mistakes. But brightly-coloured water guns aren't going to make the slightest bit of difference, you're just scaremongering.
I also have a reasonably high end wintel workstation that I've already sunk thousands into and is a year away from needing replacement. If I could buy OS X for intel to run on it I would, but I can't so thepiratebay it is. Yar!
And for every person like you who could earn them $129 buying OS X but deciding to hack up an illegal copy, there'll be ten people deciding to go with a $2499 Mac Pro instead of a Dell. You're right, I'm sure Dell is anxious to sell OS X for Dells. That doesn't mean it make sense for Apple to allow it though, does it?
Given that a lot of torrents are copyrighted content, are ISPs really going to want to do this? The moment they start caching these files on their servers, they become a huge target for lawsuits.
They already do it with HTTP proxies and Usenet servers without getting sued. So long as they are simply complying with a content-neutral communications protocol - which is basically the whole point of an ISP, I don't see how they could be held accountable. Their business is to transport bits in a particular fashion. It's not up to them to decide which bits are "good" bits and which bits are "naughty" bits.
Unfortunately, from what I've seen, they have added more hacks to the clunky rendering engine from IE5 (or earlier), instead of developing a new rendering core from scratch.
Backwards compatibility with all the crappy proprietary behaviours of older versions of Internet Explorer is pretty important to Microsoft, which is why they are still using their older rendering engine instead of replacing it with something better. They can't make big changes because they are afraid they'll break things.
Internet Explorer 8 is where you're likely to see a change like this. From what they've been saying, I think it's likely that they'll not add a further doctype switch, but implement a new rendering engine for XHTML only. Everybody using text/html will be stuck with Internet Explorer 7-level support for CSS, and everybody using application/xhtml+xml will get the new rendering engine. This has the added advantage of zero regressions - so Microsoft won't have to worry about backwards bug-for-bug compatibility.
Unfortunately, to do this, they actually need to implement XHTML...
MS has specifically stated that IE7 will not support the application/xml+xhtml mime type. This is a simple thing that most people overlook the importance of.
No, it's not. I know it looks quite similar when you are writing it, but supporting XHTML isn't just a case of adding "application/xhtml+xml" to the list of media types that get chucked through the HTML rendering engine. Apart from the obvious fatal-error-on-malformed-documents behaviour, there are changes to the DOM, changes to CSS, changes to page structure, and so on. For instance, the following code means different things in HTML and XHTML:
<table><tr><td>...</td></tr></table>
In HTML, this code creates four elements. In XHTML, it creates three elements.
There's all kinds of subtle ways in which XHTML differs from HTML, and if Microsoft don't get it right, it's going to cause a whole load of problems further down the line. XHTML is a golden opportunity to leave cruft like doctype switching and stupid CSS bugs behind once and for all, and if Internet Explorer 7 includes premature broken support for XHTML, it will be a squandered opportunity, and it will cause all kinds of problems further down the line.
IE7 fixes the Holly Hack, the box model, PNGs, the pixel jog, the double margin float,
All of these are bugfixes, not additional support for CSS.
child selectors, position:fixed,
Yes, these are improvements to CSS support.
the XMLHttpRequest object,
This is only part of draft specifications at this stage.
XML degradation
This is a workaround for proprietary behaviour that gives false positives in Internet Explorer 6. Doctype switching isn't part of any specification, it's intentional misrendering. Not to mention the fact that it wouldn't even be a problem if Internet Explorer supported XHTML in the first place.
the phantom box, percentage vs. auto, the PEEKABOO bug (Oh My God - line-height bug, too!),
More bugfixes, not additional support.
EMACScript degradation...
What are you referring to? They haven't made any changes to their JScript engine, which is their implementation of ECMAScript.
All in all, I see a lot of bugfixes, but hardly anything in the way of adding missing support for parts of CSS. Sure, they added selectors, but they missed out tables and generated content, which are huge parts of the specification. Sure, they added a workaround for people using faux XHTML, but they didn't actually add XHTML support. And I don't know what you mean by "ECMAScript degradation", but they still have a non-standard event model instead of the DOM event model.
IE7 is waaaaaaaaaaaaay closer to Firefox and Opera than IE6.
Come off it. Bugfixes are not a great leap in functionality. Sure, it's great that we finally have them, but to characterise this as closing the gap between the browsers in any meaningful way is exaggeration beyond belief.
I could honestly care less about ACID2 compliance, and the people who do are impractical pedants.
Er, some of the things that Acid2 tests for are things you are describing as fixed in Internet Explorer 7, so obviously some of the things in Acid2 are important to you.
And, wearing my impractical pedant hat, I have to point out that you are saying that people who care about Acid2 less than you are impractical pedants, which makes no sense.
It depends what you are using it for. For a complex DHTML interface for a web application that people use on a regular basis, sure, ~50KB isn't a big deal, especially when it's usually going to be coming from their cache. But for an average website that just wants to enhance particular aspects of their interface, it's ludicrous to make visitors download all that JavaScript, most of which will remain unused.
The Digg example LiquidCoooled posted is a good one. The Digg developers seem to have paid no attention to efficiency, they just dump everything they might ever possibly use onto every page regardless of whether they use one function or twenty. For instance, they reference a 36KB drag and drop library on every page on their site, but I don't see them actually using any drag and drop anywhere - do you? Or how about the fact that they reference aboutdigg.js on every page despite the fact that the code is only ever used on one specific page which most visitors aren't ever going to visit anyway?
Sure, there are a lot of instances where it's a good idea to use a library. But I think a lot of the people using libraries like this are doing so because they want to cut corners, not because it's the right tool for the job.
Slashdot Mirror
Yes, it is an important feature. But no new information is being offered here. It's repeating old information to clear up confusion caused by Slashdot reposting an article from last year.
Compliance is not a matter of degree. By pointing out that they haven't even implemented 90% of the specification, he's stating that Internet Explorer is not compliant. The opposite of what is claimed in the headline.
No. Not even close. Throw away the idea that he's arguing that Internet Explorer 7 is standards compliant. It's a complete fabrication; he never claimed that.
What he is saying is that they've done a lot of work in the area of standards compliance, there are moderate improvements, and that it doesn't really make sense to say that it supports 57.324% of the specification or whatever kind of number you can come up with, because there's really no sensible way of measuring something like that objectively.
Chris Wilson isn't a marketer, either. He's worked on Internet Explorer for years, he was on the W3C CSS working group and has his name in the acknowledgements of the specifications. I believe him when he claims to be working hard to bring Internet Explorer into compliance, but there's only so much a person can do without support from above.
Read what you quoted again. He's not saying that they don't have testcases, what he's saying is that you can't objectively quantify how far they have to go.
Please quote properly. The full quote is "there isn't an official test suite that exhaustively tests whether you comply with the standard or not." And that is true. A test suite cannot tell you if an implementation is compliant or to what degree an implementation is compliant. It can only point out particular things that are broken. If you're thinking of dividing the number of passed tests over the number of total tests, that still won't tell you how compliant an implementation is because it will be weighted according to the number of test cases for each particular language feature. If you weight them differently, then you let your own opinions about what is important into the analysis, which is why he followed up with "And any analysis you can do is going to be somewhat biased."
What a ridiculous, misleading title. Microsoft have claimed nothing of the sort. They've claimed improvements, which is true. In fact, the article quotes Chris Wilson as saying he thinks they've implemented over half of the CSS 2.1 specification, but not 90%. That's hardly insisting it is compliant, is it?
I'm definitely no Internet Explorer fan - I think Microsoft's efforts with Internet Explorer 7 have been abysmal. But this is a non-story. Everybody knows that Internet Explorer isn't compliant. Everybody who has been paying attention knows that there have been gradual but long-demanded improvements included in Internet Explorer 7.
Shame on you Taco for posting a story with such a dishonest, inflammatory headline. If this were a political website, the equivalent to what you just did would be a Democrat posting a story saying "Dubya eats babies!"
You can find out more about Lord Phillips of Sudbury, including what he's been getting up to in the House of Lords, at They Work For You.
As I was saying elsewhere, the UK has a history of passing stupid laws, and then having the rest of the country ignore or bypass them.
For example, we have a law saying that all schools must provide daily worship of a predominantly Christian nature. Over three-quarters of schools in the country are simply breaking the law or finding loopholes. As a result, the law is being relaxed, and will probably be disposed of entirely before long.
If you are approaching this from an American perspective, where bad laws like the DMCA are routinely enforced, then I can see how this might be considered an absolute disaster in terms of liberty. But from a British perspective, it's just another law to be ignored, and if anybody tries to use it, there'll be an uproar. As things stand, it hasn't even been used and there's already a backlash that has reached the House of Lords.
Actually, since the House of Lords don't have to chase after votes all the time, they help chuck out all the stupid knee-jerk laws the House of Commons come up with to make it look like they are doing something important. It's a useful component of a democratic system that mitigates one of the downsides of democracy - that the elected representatives are concerned with appearances more than the well-being of the country.
Yes, but the bookshop isn't earning all the money students are paying for Microsoft Office, their markup is relatively small. I expect it would be more profitable to sell OpenOffice CDs at half the price of Microsoft Office because it only costs the price of a blank CD to restock.
Okay, it was back in the 90s, but when I was at uni, there were plenty of UNIX workstations that didn't have either of those installed. I can't imagine things have changed so drastically in the last few years or that I went to the only university that used UNIX.
The plan is that the baby that drinks the neutron-laced super-milk will turn into some sort of terrorist-fighting mega-baby with superpowers. That's how the machine helps in the War on Terra!
They could email and ask? When you can take small websites completely offline with the amount of traffic Slashdot gets, it's irresponsible to not give any warning or caching, especially when your excuse is that you just can't wait six hours for this "cool breaking story". Hands up everybody who just couldn't wait another six hours to see Star Trek posters?
Or, if you want the techie approach, something similar to robots.txt would be simple for high-traffic websites like Slashdot to respect.
You obviously missed my point. Please show me somebody who thinks it is necessary to protect GPLed software written 43 years ago, by somebody who's made more than enough money to retire on and who died decades ago.
Isn't it awful? If people keep infringing his copyrights, John Lennon might have to quit music and get a day job! Then where will all the Beatles fans be? They'll be moaning about how they aren't getting any new Beatles music, I'm sure.
Ajax is no different to any other kind of JavaScript - if you know what you are doing, there's no reason it should cause problems for the blind or people without JavaScript. You have formed this opinion because lots of people who don't know what they are doing are using Ajax, not because Ajax inherently has this problem.
Again, Ajax is like any other JavaScript in this respect. If you know what you are doing, this isn't a problem.
Well yes, in general, if you want to add features, you have to add development time. This is to be expected.
You have that backwards. Internet Explorer handles Ajax differently because it provided the XMLHttpRequest object first. When the other browsers copied it, they implemented it differently.
In actual fact, the differences are trivial. It's a few lines of generic code to make Internet Explorer act like the other browsers. And Microsoft, rather than encouraging the different interfaces, is actually changing Internet Explorer 7 to work like the other browsers.
Web pages haven't been unified since <img> was introduced in Mosaic. What you are concerned with is addressability, another thing in which poor coders are giving a false impression.
Utter nonsense. In fact, I'd say the opposite is true. If you are concerned with look and feel, then good layout design is what you are striving for, and CSS is the way that you achieve it.
This is simply not true. You can make all the same features work, but they don't work as well, and certainly don't respond as quickly.
When web developers talk about the layout being cached, they mean the stylesheets that define the layout. Things like sidebars, headers, menus etc aren't cached themselves, they still appear in the HTML as content. It's just how they look, as defined in CSS, that is cached. You aren't avoiding downloading all of that superfluous information when you cache a stylesheet, you still have to download the content. Ajax avoids that.
Please don't. Google are good at server-side stuff, good at user-interfaces, and good at picking out the best mix of unusual features. They suck at client-side web development. GMail is great, yes, but that's because of the features and because they chose to use XMLHttpRequest - not because of the actual quality of their code. If you learn from Google's code, you'll learn wrong. IBM had a good series of tutorials on Ajax, and the DOM Scripting book is reputed to be very good. I suggest you learn from those instead.
That depends on how it's implemented. The best way of using JavaScript is to store the information it needs within the structure HTML provides. That way, anything that can parse HTML - including search engines - can easily extract the information.
For example, if you're building a photo gallery that uses Ajax to dynamically load information about the photograph from the server, you can use a normal HTML link or the <img> element's longdesc attribute to provide the URI to the extra information.
Just because Ajax uses JavaScript, it doesn't mean that you need to start ignoring HTML. If you use JavaScript properly, your Ajax content will still usually be indexed.
As an application development platform? Sure, why not. As a web application development platform? No chance.
The fundamental problem with Flash is the same as it ever was. You have a presentation format that wraps up presentation, scripting and content into one binary bundle that couples everything together so tightly it's impossible to decompose. You might as well stick a Powerpoint presentation on the web. Virtually all of Flash's other problems that people complain about are merely symptoms of this one underlying design flaw.
With a normal web application, you can do all kinds of things with the various pieces. On a slow connection? Turn off the graphics. Indexing content? Just parse the HTML. Security worries? Switch off scripting. Hate the design? Use a user stylesheet. Missing a feature? Add it with Greasemonkey. Concerned with a particular part of the web application? Link directly to it.
Flash either makes these things impossible or way more difficult than they should be because everything is tightly coupled instead of loosely coupled the way all the other web technologies are. By itself, this single factor limits interoperability, which is the whole basis for the WWW's strength. Sure, you might be able to produce a fancy interface, but you're doing it at the expense of cutting off ties to the rest of the web's technologies. It's Flash's fundamental design flaw that Adobe/Macromedia don't seem to understand or care about fixing.
Ajax, on the other hand, works with all the other WWW technologies. It doesn't invent its own way of representing content, it uses HTML. It doesn't have its own layout system, it uses CSS. Its constituent components already all exist, and, more importantly, lots of other software is built to manipulate them.
For example, if I have my browser set up to automatically make tables sortable, this works with tables in an Ajax application because Ajax applications would just use a normal, standard HTML table. The same thing hasn't got a chance of working in Flash because it doesn't build on top of existing technologies, it throws them all away and does its own thing.
Flash isn't a way of creating web applications. It's a way of creating traditional applications and making them appear in a browser window. If that's what you want, then fine, go ahead and do that. But don't pretend they are web applications, because they've thrown away everything that makes the web so powerful and replaced it with something else.
The table leg was wrapped in a bag and police had been told he had a shotgun. If you're suspected of being a terrorist, having a flourescent water gun isn't going to make the slightest bit of difference. And you fail to mention that the guy "armed with a lighter" was holding a lighter that was an imitation gun. It's a bit dishonest not to mention this crucial fact and fail to link the article properly so most Slashdotters won't bother reading the article, don't you think?
Yes, all of these were regrettable mistakes. But brightly-coloured water guns aren't going to make the slightest bit of difference, you're just scaremongering.
And for every person like you who could earn them $129 buying OS X but deciding to hack up an illegal copy, there'll be ten people deciding to go with a $2499 Mac Pro instead of a Dell. You're right, I'm sure Dell is anxious to sell OS X for Dells. That doesn't mean it make sense for Apple to allow it though, does it?
The class libraries are available under the Apache 2.0 license. The compiler itself is proprietary.
They already do it with HTTP proxies and Usenet servers without getting sued. So long as they are simply complying with a content-neutral communications protocol - which is basically the whole point of an ISP, I don't see how they could be held accountable. Their business is to transport bits in a particular fashion. It's not up to them to decide which bits are "good" bits and which bits are "naughty" bits.
Backwards compatibility with all the crappy proprietary behaviours of older versions of Internet Explorer is pretty important to Microsoft, which is why they are still using their older rendering engine instead of replacing it with something better. They can't make big changes because they are afraid they'll break things.
Internet Explorer 8 is where you're likely to see a change like this. From what they've been saying, I think it's likely that they'll not add a further doctype switch, but implement a new rendering engine for XHTML only. Everybody using text/html will be stuck with Internet Explorer 7-level support for CSS, and everybody using application/xhtml+xml will get the new rendering engine. This has the added advantage of zero regressions - so Microsoft won't have to worry about backwards bug-for-bug compatibility.
Unfortunately, to do this, they actually need to implement XHTML...
No, it's not. I know it looks quite similar when you are writing it, but supporting XHTML isn't just a case of adding "application/xhtml+xml" to the list of media types that get chucked through the HTML rendering engine. Apart from the obvious fatal-error-on-malformed-documents behaviour, there are changes to the DOM, changes to CSS, changes to page structure, and so on. For instance, the following code means different things in HTML and XHTML:
In HTML, this code creates four elements. In XHTML, it creates three elements.
There's all kinds of subtle ways in which XHTML differs from HTML, and if Microsoft don't get it right, it's going to cause a whole load of problems further down the line. XHTML is a golden opportunity to leave cruft like doctype switching and stupid CSS bugs behind once and for all, and if Internet Explorer 7 includes premature broken support for XHTML, it will be a squandered opportunity, and it will cause all kinds of problems further down the line.
All of these are bugfixes, not additional support for CSS.
Yes, these are improvements to CSS support.
This is only part of draft specifications at this stage.
This is a workaround for proprietary behaviour that gives false positives in Internet Explorer 6. Doctype switching isn't part of any specification, it's intentional misrendering. Not to mention the fact that it wouldn't even be a problem if Internet Explorer supported XHTML in the first place.
More bugfixes, not additional support.
What are you referring to? They haven't made any changes to their JScript engine, which is their implementation of ECMAScript.
All in all, I see a lot of bugfixes, but hardly anything in the way of adding missing support for parts of CSS. Sure, they added selectors, but they missed out tables and generated content, which are huge parts of the specification. Sure, they added a workaround for people using faux XHTML, but they didn't actually add XHTML support. And I don't know what you mean by "ECMAScript degradation", but they still have a non-standard event model instead of the DOM event model.
Come off it. Bugfixes are not a great leap in functionality. Sure, it's great that we finally have them, but to characterise this as closing the gap between the browsers in any meaningful way is exaggeration beyond belief.
Er, some of the things that Acid2 tests for are things you are describing as fixed in Internet Explorer 7, so obviously some of the things in Acid2 are important to you.
And, wearing my impractical pedant hat, I have to point out that you are saying that people who care about Acid2 less than you are impractical pedants, which makes no sense.
It depends what you are using it for. For a complex DHTML interface for a web application that people use on a regular basis, sure, ~50KB isn't a big deal, especially when it's usually going to be coming from their cache. But for an average website that just wants to enhance particular aspects of their interface, it's ludicrous to make visitors download all that JavaScript, most of which will remain unused.
The Digg example LiquidCoooled posted is a good one. The Digg developers seem to have paid no attention to efficiency, they just dump everything they might ever possibly use onto every page regardless of whether they use one function or twenty. For instance, they reference a 36KB drag and drop library on every page on their site, but I don't see them actually using any drag and drop anywhere - do you? Or how about the fact that they reference aboutdigg.js on every page despite the fact that the code is only ever used on one specific page which most visitors aren't ever going to visit anyway?
Sure, there are a lot of instances where it's a good idea to use a library. But I think a lot of the people using libraries like this are doing so because they want to cut corners, not because it's the right tool for the job.