After I followed and read some of the links linked in ways to talk with Internet Explorer team and thought about it a little I found a nice idea how Internet Explorer could remain backwards compatible with their current mess web, while making standard compliant websites, using CSS2.1, PNG, HTTP, XHTML and more, possible. It all came down to:
application/xhtml+xml
That is a MIME type Internet Explorer currently doesn't support. Internet Explorer does support text/html in a way, but it doesn't has native support for XHTML yet and in this case that is a good thing. Of course I could have sent the lead developer a simple e-mail saying: 'application/xhtml+xml', but I don't think that will work. First, he would have to know I'm talking about a MIME type and second, he would have to know it is about Internet Explorer and not about spam. Third, I want my idea to be available for everyone, not just the lead developer.
Some already might have guessed the simple idea and I would really want to know all the potential flaws in it. Besides that Internet Explorer didn't plan to support it anyway. Here is the deal:
text/html and works in Internet Explorer.
text/html. It is also highly unlikely that their audience uses Internet Explorer.
application/xhtml+xml, the XHTML MIME type.
Quick conclusion: Internet Explorer could choose to implement application/xhtml+xml correctly (as in really good, Mozilla like) and support, for real, standards only in application/xhtml+xml mode. This has two direct advantages:
text/html.
A natural extension of Standards Mode versus Quirks Mode. Now we can have, in addition, Standards (We Really Mean it this Time!) Mode, triggered not by a DOCTYPE declaration, but by choice of MIME type.
The only downside I see is that it will still be impossible to achieve Standards-compliant behaviour in IE when rendering HTML 4 pages. But that may be a small price to pay.
And, hey, this would finally provide a reason for people to author in XHTML. (Let's face it, most people don't use any of the features that flow from its being XML, and currently would be better-off authoring HTML 4. Now they'd actually get some practical benefit from XHTML)
Great Idea Anne, and if neither you nor Jacques can think of a reason why this would be bad, then it must be good ;-]
I agree that this seems a good idea, and it could really push webstandards!
Slick.
Of course, what are we talking about? When will IE7 (the real one) reach the markets? 2006? 2007? You'll have to get the OS to test it, too, and hope things work according to the standards. Because if they don't... well, you know of another MIME-type?
Well, does that make my mind also great since I had considered the same thing a few months back, but dismissed it as probably a nice pipedream...
The problem I see is how do you propose to send the document as application/xhtml+xml will you be limiting the author to using server-side content negotiation or will you allow the user-agent to read the x(ht)ml document and determine from some other level, for example the <meta /> element.
As I see it the only major problem apart for the fact it would probably take above five-years for scores of netcitizens to bother upgrading to 'Explorer with Added XHTML Mode', would it only be the Geeks who would care enough to author XHTML with the said MIME.
or will you allow the user-agent to read the x(ht)ml document and determine from some other level, for example the <meta /> element.
G-d, I hope not! Document-sniffing, to override the Server-set MIME-type is utterly evil (and a clear violation of Specs). If I send you a document as text/plain, I really mean it!
As I see it the only major problem apart for the fact it would probably take above five-years for scores of netcitizens to bother upgrading to 'Explorer with Added XHTML Mode', would it only be the Geeks who would care enough to author XHTML with the said MIME.
The uptake of IE/6 was more rapid than that. But, "past performance is no guarantee of future results." Right now, only Geeks have a reason to author XHTML with the correct MIME type. Give the rest a reason to do so ...
I agree it's an evil idea using the meta method and not really a solution - I just couldn't think of a suitable alternative offering which could slip through the safety net for the document type sniffing.
Just curious though; how many commercial webmasters do you think will be prepared to see "Yellow Screen of Death" due to the XML-Processor halting on error when their XHTML is not well-formed.
It's a good idea but I think too many would be scared to place their syntax where their mouths are?
G-d, I hope not! Document-sniffing, to override the Server-set MIME-type is utterly evil (and a clear violation of Specs). If I send you a document as text/plain, I really mean it!
Indeed, nothing annoys me more than having a javascript or some HTML or whatever in a .txt file, sent as text/plain being executed in IE.
Just curious though; how many commercial webmasters do you think will be prepared to see "Yellow Screen of Death" due to the XML-Processor halting on error when their XHTML is not well-formed.
Mozilla zealot. :P (Opera does not display it in yellow but in normal white).
I do not know where I read it, but there seems to be an Apache module which can do Tidy if the document doesn't parse correctly.
And that's why software needs to be improved and people should wine about unencoded ampersands all over the place instead of not caring about it. The current standard community shows you can do something with invalid crap, not with standards.
(I could have said that in a better way probably, but that is the problem. People think they improve the web by advocating a little and creating almost validating websites, where websites actually should be completely valid since they would otherwise crash on launch.)
It's a good idea but I think too many would be scared to place their syntax where their mouths are?
Reliably producing well-formed XHTML on a commercial web site is going to require serious changes in production techniques. Most webmasters are probably not ready for that. Not by a long shot.
Fortunately, they have a few years to prepare themselves.
About those serious changes in production techniques, I thought they were always advocating stuff like in the informatics sector you have to study all time, if you don't adapt new techniques all the time even after 6 months you're a lot behind
. I suppose that would mean I'm backwards, but well... ;)
Yes, all suggestions sound really nice.
But do you really think MS will implent this in IE 7 when they've already said no XHTML 2 support?
Or did I just miss something?
Until IE7 final is there none of the statements can't be withdrawn.
But do you really think MS will implent this in IE 7 when they've already said no XHTML 2 support? Or did I just miss something?
XHTML2 is not a finished Spec. There is no way MS would announce support for a Spec that is not finished.
They've implemented draft Specs in the past and gotten pilloried for it (when their implementation violates the finished Spec).
If the XHTML 2 Spec is finalized sufficiently far in advance, they can always, as Frenzie says, change their minds.
Good thinking, Anne.
I wonder what the chances are of Microsoft actually implementing this. It's probably just a pipe dream, but it would make for an elegant solution to the backward-compatibility dilemma.
I really REALLY like this idea. I don't see any flaws in it. It'll even still allow people who don't want to code correctly, to make a site. Not that coding correct is difficult.
I think adding an XHTML mode to IE 7 would be a good idea. And as it seems that Internet Explorer isn't dead, maybe we can tell Dave Massy about this great idea as well? Will you take upon you the responsibility of doing so, Anne? I've already commented my wishes for the next Internet Explorer in that thread.