Deliberately invalidating (more importantly, rendering ill-formed) every page of your site is a fine idea, unless the IE Team takes the unlikely step of following Anne van Kesteren’s clever suggestion.
Anne’s suggestion seems unlikely, but it’s the only plausible route to ever bringing true Standards support to IE. Everybody else ought to be rooting for it.
One of the key points of Joel’s article is that not breaking backwards compatibility was a high priority at MS. You are never going to see IE change its behaviour in a way that breaks existing web pages by the millions.
On the other hand, MS is bundling the MathPlayer 2.0 plugin (which brings application/xhtml+xml and MathML support to IE/6) with Encarta. They already support rendering X(HT)ML for local pages. It would not be surprising at all if they decided that a more “integrated” approach would be beneficial to their plans for IE.
With a cleaner codebase, guaranteed well-formed input and no issues of maintaining backwards compatibility, it would be a lot easier for them to support Standards. Anne’s suggestion is unlikely, but not wildly implausible.
And it fits with other things they are doing (unlike most other “suggestions” to the IE team).
What I got out of the article was they’re betting the farm on the rich client, and their biggest compitetor is web applications and potentially themselves if they increase IE’s advanced DHTML ability, for example. Microsoft employs a lot of very smart people, and if the stagnation of IE is not a resources problem, it is a strategic decision.
[T]he stagnation of IE is not a resources problem, it is a strategic decision.
I agree. As I said, they have strong reasons not to change IE’s behaviour in rendering existing web pages. Which means that modulo their interest in supporting new technologies (from XAML to MathML), they have no reason to touch the existing engine.
This is the only plausible path for them to make significant changes in their engine, without breaking stuff.
As to the rich-client/web-app thing, MS is big enough to play both sides of the street, and knows that it has to play both sides of the street, if it is going to ensure its own survival.
Deliberately invalidating (more importantly, rendering ill-formed) every page of your site is a fine idea, unless the IE Team takes the unlikely step of following Anne van Kesteren’s clever suggestion.
Anne’s suggestion seems unlikely, but it’s the only plausible route to ever bringing true Standards support to IE. Everybody else ought to be rooting for it.
I don’t know how Anne could read Joel’s API article and then write about improving IE. It’s not going to happen in my lifetime.
One of the key points of Joel’s article is that not breaking backwards compatibility was a high priority at MS. You are never going to see IE change its behaviour in a way that breaks existing web pages by the millions.
On the other hand, MS is bundling the MathPlayer 2.0 plugin (which brings
application/xhtml+xmland MathML support to IE/6) with Encarta. They already support rendering X(HT)ML for local pages. It would not be surprising at all if they decided that a more “integrated” approach would be beneficial to their plans for IE.With a cleaner codebase, guaranteed well-formed input and no issues of maintaining backwards compatibility, it would be a lot easier for them to support Standards. Anne’s suggestion is unlikely, but not wildly implausible.
And it fits with other things they are doing (unlike most other “suggestions” to the IE team).
What I got out of the article was they’re betting the farm on the rich client, and their biggest compitetor is web applications and potentially themselves if they increase IE’s advanced DHTML ability, for example. Microsoft employs a lot of very smart people, and if the stagnation of IE is not a resources problem, it is a strategic decision.
I agree. As I said, they have strong reasons not to change IE’s behaviour in rendering existing web pages. Which means that modulo their interest in supporting new technologies (from XAML to MathML), they have no reason to touch the existing engine.
This is the only plausible path for them to make significant changes in their engine, without breaking stuff.
As to the rich-client/web-app thing, MS is big enough to play both sides of the street, and knows that it has to play both sides of the street, if it is going to ensure its own survival.
You might want to read the list of goals of the lead developer, more specifically, point 4.