The <?xml> prolog, strict mode, and XHTML in IE


I realized as I read through the comments to my last blog post that I forgot to mention one important item that was in my presentation.  We have fixed the DOCTYPE switch so it will skip an XML prolog, so that valid XHTML can be handled in strict compliance mode rather than quirks mode.

I’ve also been reading comments for some time in the IEBlog asking for support for the “application/xml+xhtml” MIME type in IE.  I should say that IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations.  We fixed the problem with our DOCTYPE switch explicitly so that this mechanism is easier to use, and it is generally easy to set up most servers to conditionally serve content as “text/html” when the “application/xml+xhtml” MIME type is not supported.

Why aren’t we supporting XHTML when it’s served as the “application/xml+xhtml” media type in IE7?  I made the decision to not try to support the MIME type in IE7 simply because I personally want XHTML to be successful in the long run.  I love XHTML (go look, my name is in the credits for XML 1.0); it’s capable of being truly interoperable if done right.  With most of our platform resources in IE7 outside of security work being spent on improving our CSS support, if we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs.  It is highly unlikely we could support XHTML well in this way; in particular, we would certainly not detect a few error cases here or there, and we would silently support invalid cases.  This would, of course, cause compatibility problems based on parser error handling in the future, which XML is explicitly trying to avoid; we don’t want to cause another mess like the one with current HTML error handling (rooted in compatibility with earlier browsers – you can blame me for that personally somewhat, but not IE).  I would much rather take the time to implement XHTML properly after IE 7, and have it be truly interoperable – but I did want to unblock deployment of XHTML as best we could, which is why we made sure to address the XML prolog/DOCTYPE issue.

 – Chris Wilson

Comments (119)

  1. Anonymous says:

    Chris, an SGML comment will also trigger quirks mode if included before the DOCTYPE. Is this fixed too?

  2. PatriotB says:

    Thanks Chris, and everyone else on the IE blog. The amount of openness and communication in this blog since Beta 1 was released has been excellent. Keep up the good work!

  3. Anonymous says:

    And yet again an interresting post on issues people were wondering about. Thanks a lot Chris.

  4. Anonymous says:

    > The amount of openness and communication in this blog since Beta 1 was released has been excellent.

    I think it’s more the fact that the IE team are actually making real progress on IE now, the first time for years – there’s actually something to say!

  5. Anonymous says:

    Completely the right decision.

    Well done for not bowing into half-heatedly supporting it, which would just make more of a mess than we’ve got at the moment.

    It means the new feature list is one item shorter, but it’s by far the best thing to do for interoperability.

    I look forward to full XHTML compatibility in IE8 (hopefully not for Windows Vista 2).

  6. Anonymous says:

    IE7 won’t be up to standards without properly handling proper doctype and mimetpye associations. While it’s still a black mark it’s not really something me and other designers commonly talk about or care too much about compared to other as you personally put it head-bangers.

    There are common reminders that XML declaration (which is properly placed BEFORE the doctype) will throw IE(6 and below) in to quirks mode. Assuming we can still use for example html comments BEFORE the doctype to throw IE in to quirks mode while still having a doctype I don’t think you’ll disturb too many nests which is a highly desired practice on part of MS and something I think is in the good category.

    Remember a LOT of pages depend on IE’s Quirks mode and having comments before the doctype no longer throwing IE in to quirks mode will force people to use serverside code to NOT send the doctype to IE7. So XML declaration before Doctype = standards unless there are comments (with or without the XML declaration) and still give us quirks.

    A little serverside scripting will allow Web Developers to properly serve mimetpyes according to the UA and most XHTML 1.1 sites (like my own at this moment in time) server XHTML 1.1 as text/html anyway to all browsers (though I will be fixing this issue with the next release of my own site and of course be paying attention to IE7).

    In the end I think you guys are doing a great job and I’m very anxious to see the end results in both security and (x)HTML rendering!

  7. Anonymous says:

    Instead of hacking the HTML parser to bits, why not use the XML parser?

  8. Anonymous says:

    As the author of "Serving up XHTML with the correct MIME type" (click my name above for the link), I must say I am disappointed that IE7 will not have support for application/xhtml+xml; however, it is better to have no support at all than some sort of half-assed buggy support.

    I’m not sure why it is so difficult to do support for this MIME type. Could it not be handled by the XML parser completely? Gecko seems to have no trouble with it.

  9. Anonymous says:

    I can understand and respect the decission to not add XHTML support as an ugly hack, however:

    <blockquote>s to conditionally serve content as “text/html” when the “application/xml+xhtml” MIME type is not supported</blockquote>

    Internet Explorer does not seem to support this option. The following is the accept header sent to me by several IE6 users:

    <blockquote>

    image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, +application/vnd.ms-powerpoint, application/msword, */*

    </blockquote>

    When it comes to application/xhtml+xml, text/xml, or text/html IE doesn’t provide a preference.

  10. Anonymous says:

    As one who previously commented on the application/xhtml+xml issue, I’m disappointed to hear this news . . . although I totally agree with other posters that the openness and communication of IEBlog about IE7 has been WONDERFUL and very appreciated! Even without this MIME fix, I’m very much looking forward to IE7 being out, you’re making some wonderful improvements that are very welcome.

    I do hope this MIME issue is fixed soon, though. While XHTML can be served as text/html, this is not advisable for many reasons, as Ian Hixie and others (including Simon) have pointed out: http://www.hixie.ch/advocacy/xhtml

    Thanks again for the info!

  11. Anonymous says:

    After everything we’ve heard that’s coming in IE7, I can’t help but wonder what we will see in IE8. Don’t get me wrong, I really appreciate what you guys do (and will be doing) on IE 7, but I think no one would argue that IE 7 is more a product with a goal to undo the damage done by IE 6, which hasn’t been updated for YEARS! The most important thing to me is, will we have to wait another 5 years to see IE 8?

  12. Anonymous says:

    Maybe I have things mixed up, but I thought that all that was necessary for XHTML support was:

    1) XML processor

    2) full support of CSS display property (including table)

    Is it because of other issues? Such as incremental rendering (which I’m not sure IE’s XML processor allows) and form controls (which only CSS3 UI covers)?

  13. Anonymous says:

    “application/xml+xhtml” MIME type must be the first thing fixed on the list, because xhtml is the future and html is the past; you have 1 year to fix this, isn’t enough?

    Off-topic:

    Please change the menus for IE7, (right-click menu, options menu, etc.) they are the same since IE4. For example, properties pane is very basic. Icons are old, help system is old, please update them too, since there will not be another release in 3 years from now.

    And something I must say now, not later. Nobody hurry IE7 developers to complete the product (for Windows XP at least) on May 2006. You better release the final browser at the same date with Windows Vista shipping and we, all the internet users, will be happier.

    BTW: Make me switch back to IE7.

  14. Anonymous says:

    > IE7 won’t be up to standards without properly handling

    > proper doctype and mimetpye associations. While it’s

    > still a black mark it’s not really something me and other

    > designers commonly talk about or care too much about

    > compared to other as you personally put it head-bangers.

    Well, you at least get to keep valid text/html + html4 and text/html+xhtml1.0

    > Remember a LOT of pages depend on IE’s Quirks mode and having

    > comments before the doctype no longer throwing IE in

    > to quirks mode will force people to use serverside code

    > to NOT send the doctype to IE7. So XML declaration

    > before Doctype = standards unless there are comments (with

    > or without the XML declaration) and still give us quirks.

    They rely on quirks because of IE’s buggy implementation. If the author knew enough as to have insight on quirks/strict and be able to use XML declaration to trigger it, I’d guess that their websites are standards-compliant to an extend.

    Not only that, but allowing XML declaration while keeping Strict mode on makes content-negociation much easier.

    > Instead of hacking the HTML parser to bits, why not use the XML parser?

    You steel need to hook the parser and the renderer, and XHTML as application/xhtml+xml behaves differently than text/html on many level (including CSS and quite a lot of Javascript constructs, document.write and innerHTML are not allowed to work anymore for example, and things like getElementsByTagName or createElement should become case sensitive)

    Which is why they can’t use MSXML out of the box, and won’t just patch the existing HTML engine.

    > I’m not sure why it is so difficult to do support

    > for this MIME type. Could it not be handled by the XML

    > parser completely? Gecko seems to have no trouble with it.

    One of the issues here are that some behaviours change slightly to greatly when switching from text/html to application/xhtml+xml. And many of them are yet-to-explore corner cases.

    > When it comes to application/xhtml+xml, text/xml,

    > or text/html IE doesn’t provide a preference.

    Check if application/xhtml+xml is explicitely in the Accept header, if it ain’t send text/html.

  15. Anonymous says:

    XML declarations are useless in a text/html environment, so why even change that behavior when you just said application/xhtml+xml won’t be supported?

  16. Anonymous says:

    > We have fixed the DOCTYPE switch so it will skip an XML prolog, so that valid XHTML can be handled in strict compliance mode rather than quirks mode.

    You can already use valid XHTML in strict compliance mode. The XML prolog is not only not mandatory, but it’s discouraged by Appendix C. People following the specifications are not affected by the old style doctype switching.

    > we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations.

    Er, the very first compatibility recommendation tells us to avoid using the XML prolog.

    It was my understanding that you were attempting to keep backwards compatibility for quirks mode. Surely changing doctype handling to render what would previously be rendered in quirks mode so that it now gets rendered in strict mode contravenes that?

    > I would much rather take the time to implement XHTML properly after IE 7, and have it be truly interoperable

    Good news, I completely agree.

    > I did want to unblock deployment of XHTML as best we could

    I don’t see how the XML prolog is blocking XHTML development; if you are serving XHTML as text/html, you shouldn’t be including it anyway.

    > Maybe I have things mixed up, but I thought that all that was necessary for XHTML support was:

    > 1) XML processor

    > 2) full support of CSS display property (including table)

    No, XHTML support is quite a bit more complicated than that. Character encodings rules are different, the DOM API changes, the actual page structure can change (e.g. TBODY isn’t a required or implied element in tables), even CSS is different.

    > document.write and innerHTML are not allowed to work anymore for example

    I don’t believe this is the case. Just because your favourite XHTML user-agent doesn’t support it, it doesn’t mean that the specifications forbid it.

    > Check if application/xhtml+xml is explicitely in the Accept header, if it ain’t send text/html.

    Correct support for content negotiation isn’t quite that simple. You are completely ignoring quality values – your suggestion breaks things in some circumstances. You also need to send a Vary header. Read Simon Jessey’s article linked to above, that describes how to do conneg correctly.

    > Strictly speaking, this is not correct – this only applies to the "XHTML 1.0 Transitional" document type [1] you MAY send as "text/html".

    This is wrong. You can send any XHTML 1.0 document that follows Appendix C as text/html. There’s no requirement that it be XHTML 1.0 Transitional.

    > It stays the same story: Use any HTML document type for HTML, and "XHTML 1.0 Transitional" for XHTML

    Don’t do that. There’s no need to put up with XHTML Transitional – new documents should use Strict, not Transitional.

  17. Anonymous says:

    "http://news.zdnet.com/Hackers+work+to+exploit+latest+Firefox+flaw/2100-1009_22-5863451.html

    Firefox is better?"

    https://bugzilla.mozilla.org/show_bug.cgi?id=307259

    That bug is already patched and will be in Firefox 1.0.7 shortly. There’s also a workaround provided by Mozilla to fix it yourself. Thanks for playing!

  18. Anonymous says:

    Why should I have to download an entire new version of Firefox just to get a patch for one bug? If I download a new version, I get EVERY change (and potential new bug) that has gone in since the last version. I just want a single bug fixed.

    IE, for all of the problems you think it has, will issue patches for EXISTING versions of IE that ONLY fix the bug in question. They don’t make me download an entire new version of the product to fix a single security problem.

    Why can’t Firefox release patches instead of making users re-download the entire browser every time there is a major bug? This has been the reason for every dot release during the last six or eight months.

  19. Anonymous says:

    "Why can’t Firefox release patches instead of making users re-download the entire browser every time there is a major bug? This has been the reason for every dot release during the last six or eight months."

    http://kb.mozillazine.org/Software_Update

    LOL! I’m using the Firefox small patching service everyday to update to new nightly builds. It’s going to become a main feature in Firefox 1.5 this year. When’s IE7 coming out?

  20. Anonymous says:

    In answer to Jim above.

    Although you may be right about the <?xml> prolog not being encouraged for compliance, the larger issue is that of compatibility. Opera and Firefox ignore the prolog and render pages in compliance mode if it is included. For compatibility across browser platforms I would prefer if IE did the same.

    Remember that the real goal for all of us is a standard platform for web development. Web standards are not sacrosanct. Indeed, if standards get in the way of compatibility then we can always change the standard as the WHATWG has demonstrated.

    What we want is a level playing field not a religous adherence to standards defined several years before any practical uptake.

  21. Anonymous says:

    Updating to a new nightly build is not a patch. It’s downloading an entire new version.

    If 100 people check in code changes or fixes in a day, when you download the new nightly, you get all of those changes.

    If I run the last RELEASED version of Firefox and then download today’s nightly build, how many days of code churn do I get in order to just fix one bug? 30? 60? How do I know that any one of those changes doesn’t destabilize the build or introduce a NEW security hole?

    I just want a patch for the RELEASED version of Firefox that fixes the bug. Why do I have to get a whole new version? IE doesn’t make me. The IE team releases patches to EXISTING versions. Firefox almost never has.

    If I have thousands of desktops in a corporate environment, am I going to want a build of known quality with a known problem or am I going to go through all of the work to deploy firefox AGAIN to every desktop with a build of UNKNOWN quality just to fix one bug? Why can’t I just get a patch? Where is my patch?

  22. Anonymous says:

    "I just want a patch for the RELEASED version of Firefox that fixes the bug. Why do I have to get a whole new version?"

    "Why can’t I just get a patch? Where is my patch?"

    https://addons.mozilla.org/messages/307259.html

    There’s your patch, and yes, it works on the latest release.

  23. Anonymous says:

    Amazing. For about the third time ever, they didn’t just increment the version number and make everyone download a new version of Firefox. I’m impressed.

    Now, if Firefox can go six months without releasing an entire new version to fix a security problem, I’ll be even more impressed.

  24. Anonymous says:

    http://news.com.com/2100-7349_3-5857338.html

    I’d like Microsoft to at least finish releasing patches.

  25. Anonymous says:

    Dean,

    > Although you may be right about the <?xml> prolog not being encouraged for compliance, the larger issue is that of compatibility. Opera and Firefox ignore the prolog and render pages in compliance mode if it is included. For compatibility across browser platforms I would prefer if IE did the same.

    I was under the impression that Opera worked in the same way as Internet Explorer 6. However, reading this document:

    http://www.opera.com/docs/specs/doctype/

    …it seems they’ve changed this in later versions.

    You are correct, the larger issue is that of compatibility. If you use the XML prolog, your results will vary across different browsers and even different versions of browsers. There is no benefit to be had in Internet Explorer changing behaviour in this regard.

    I don’t see any problems in continuing the Internet Explorer 6 behaviour. The only time an XML prolog is necessary is when you are using a character encoding other than UTF-8 or UTF-16, and when that occurs, you are walking into a real minefield with some browsers ignoring the prolog, others ignoring meta elements, others taking meta elements in precedence over HTTP headers, and all of it varying with the version of the browser in question.

    My belief is that the only situations in which an XML prolog is necessary in a text/html document are irreperably incompatible. There’s no saving us from that, so this doctype switching change is futile.

    > Remember that the real goal for all of us is a standard platform for web development.

    Indeed. But using an XML prolog in a text/html document doesn’t bring us any closer to that goal, and changing behaviour can only break things for people who have built things that (knowingly or otherwise) rely on that behaviour.

    Yikes II,

    > I just want a patch for the RELEASED version of Firefox that fixes the bug. Why do I have to get a whole new version? IE doesn’t make me. The IE team releases patches to EXISTING versions. Firefox almost never has.

    This is not true.

    Just because the only thing you see in the GUI is "Internet Explorer 6", that doesn’t mean there aren’t minor versions just like all other software. What you call "Internet Explorer 6" is actually "Internet Explorer 6.034.8957" or similar.

    Firefox minor releases are exactly the same as that. The upgrade to 1.0.7 will not include all development done on Firefox since 1.0.6 was released. That happens on another branch. 1.0.7 will only include bug fixes, just as you wish.

  26. Anonymous says:

    <strong>May we please have multiple background images for IE7?</strong>

    This would be the grand daddy of all css selectors! Here is the <a href="http://www.w3.org/TR/2005/WD-css3-background-20050216/#layering&quot; title="Multiple Background Images">spec</a>.

    Safari has support with Opera and FF coming soon! This would be a web designers dream come true!

    Serously, please consider this option in IE7. I know its CSS3 but hey take a risk, help the community out!

    <a href="http://www.456bereastreet.com/archive/200509/custom_borders_with_advanced_css/">example article</a>

    -ryan

  27. Anonymous says:

    I’m really glad to see something happening with XHTML support in IE. When this happens, we look forward to making our MathPlayer plugin provide MathML support as we currently do for MathML in HTML.

  28. Anonymous says:

    Thank you for not adding application/xhtml+xml "support" by hacking it into the HTML code path. The Web will be better served by a proper implementation even if it takes longer.

    Commenters who think proper XHTML support is only a matter of using another parser should be aware that the changes requiring more work are in making the layout use the XML DOM. There are subtle differences:

    http://www.mozilla.org/docs/web-developer/faq.html#xhtmldiff

  29. Anonymous says:

    Glad to see that for once, MS is putting quality first. If they can’t do application/xhtml+xml properly, they ain’t doing it. Man, where were you in the last 10 years of Microsoft Software development… when they needed it!

    Oh, and uhm… so, Billy G. said that Summer 2005, a public beta of IE7 would be out… I know Summer isn’t officially over yet,… but most of us are still waiting…

    (read: A MSDN Developer release only, DOES NOT COUNT IN ANYONE’S BOOK, AS PUBLIC)

  30. Anonymous says:

    I am glad to read that Internet Explorer 7 will not choke on XML prologs as Internet Explorer 6 does, but after that, this is very disappointing news. If the maker of the most common browser does not support standards extensively, developers are prevented from using them extensively or at least without ugly browser-specific work-arounds.

    That said, I am pleased to see you being so forthcoming about the problems that will remain in IE7 so Web developers know more of what to expect when it arrives.

  31. Anonymous says:

    > Strictly speaking, this is not correct – this only

    > applies to the "XHTML 1.0 Transitional" document

    > type [1] you MAY send as "text/html".

    As far as I know this applies to every "HTML compatible" XHTML 1.0 flavour.

    And it seems to me that all 3 are as long as you don’t use external modules.

    XHTML 1.0 Transitional is compatible with HTML 4.01 Transitional, 1.0 Strict with 4.01 Strict and 1.0 Frameset with 4.01 Frameset.

  32. Anonymous says:

    RSS Feed For This One Is Messed Up 😉

  33. Anonymous says:

    I am *really* impressed by the attitude change shown by the IE team. If you can’t implement something according to the standards, then don’t do it at all. You have made the right decision and I hope to see a well implemented parser/renderer for true XHTML documents in the next version of IE.

    However, as people have mentioned, it would seem sensible if IE fixed it’s http headers to reflect the mime types that it accepts. Currently, the accept headers are sub-par, and if you believed them, IE doesn’t even support HTML :S

  34. Anonymous says:

    Yet another very interesting post.

    Thanks Chris

  35. Anonymous says:

    > [To use "application/xhtml+xml"] Check if application/xhtml+xml is explicitely in the

    > Accept header, if it ain’t send [the resource as] text/html.

    Strictly speaking, this is not correct – this only applies to the "XHTML 1.0 Transitional" document type [1] you MAY send as "text/html".

    It stays the same story: Use any HTML document type for HTML, and "XHTML 1.0 Transitional" for XHTML, as long as you don’t switch MIME and document type together (using "XHTML 1.0 Transitional" as "text/html" for IE, and "XHTML 1.1" as "application/xhtml+xml" for other user agents claiming to accept that MIME type, for example).

    [1] http://www.w3.org/TR/xhtml-media-types/#summary

  36. Anonymous says:

    I’m actually not to sure exactly how the frameborder="0" attribute is supposed to work, but when the border is removed via the frameborder attribute within a <frame> element (<frame frameborder="0" />) the space between the two remain.

    Is this supposed to be the case, where another attribute or CSS declaration should remove the gap?

    If not, would it be possible to correct IE 7 in this respect, where the spacing between each frame is removed?

  37. Anonymous says:

    This is great news. I’ve been pleading for *not* supporting the application/xhtml+xml MIME type until XHTML support is truly complete ever since I heard IE7 is coming out. Of course I would’ve preferred XHTML support in IE7, but I understand if that’s not where the priorities are.

    Many people seem to think that proper treatment of XHTML just means you run it through and XML parser and check for well-formedness. That’s not true. Proper XHTML support means you need changes to the DOM (namespace-aware methods mainly, like createElementNS), changes to the CSS box model (e.g. default height of html and body) and a few other things.

    Until IE can do *all* of those correctly, I don’t want it to accept application/xhtml+xml.

  38. Anonymous says:

    @Yikes II

    Maybe you should read more about the thing called "security patches" and "stability patches". Firefox 1.0 is frozen, this means that no additional feature can be added, and that every modification to it can be only _bug fixes_.

    Technically, the third number of Firefox’s version number isn’t even about _versions_, it’s the _revision_ ID, first is major version and second is minor version. (optional fourth is the build).

    Sooo from FF 1.0.6 to 1.0.7 you don’t change of version, you change of revision to include the bug patches of the latest revision (which, please check the changelogs if you don’t believe me, are the only ones allowed to be checked in). 1.0.6 was likewise a bug fixing revision (restoring an API compatibility), and 1.0.5 was a bugfixing and security patching revision.

    What you don’t seem to grasp is that while Microsoft indeed releases binary patches for MSIE (said binary patching being available in 1.5 btw) this does not mean that the version/revision/build ID of your IE does not change. It’s just that you don’t "get" (and probably don’t even check) IE’s version numbering.

  39. Anonymous says:

    I’m not sure if anyone mentioned this, but this means a few more years of no mixed namespaces, you can’t do mixed namespaces with text/html. Some of us were hoping we could start to use that feature, but I guess we can’t.

  40. Anonymous says:

    What about supporting ‘application/xml+xslt’, not just the nonstandard ‘text/xsl’, in the xml-stylesheet processing instruction and in the file type associations? Since text/xsl is already processed as XML, there would be no changes necessary; you’d treat them the same…

  41. Anonymous says:

    John A. Bilicki III wrote, "Remember a LOT of pages depend on IE’s Quirks mode and having comments before the doctype no longer throwing IE in to quirks mode will force people to use serverside code to NOT send the doctype to IE7."

    If you’re relying on quirks mode rendering, you shouldn’t be sending the DOCTYPE to any browser. Other browsers also distinguish between a strict compliance/standards mode and a quirks mode, so send it to quirks mode on all platforms.

  42. Anonymous says:

    "There’s no need to put up with XHTML Transitional – new documents should use Strict, not Transitional."

    One might think that, but "Transitional" and "Strict" are really misnomers in that these labels do not reflect the full scope of differences between the two DTDs. Take link targets, for example; there is no equivalent offering in the Strict DTD to which one might transition. The frameset DTD does not count, either, because link target attributes or for elements in documents within object elements or framesets, not for frameset documents themselves.

    Nor are so-called transitional documents ticking toward an expiration date, so there will not necessarily ever be a complete transition to the less-capable so-called strict DTD.

    I would love to see a proper strict DTD that does not cripple functionality, but until that happens, do not be surprised if many documents that otherwise conform to the strict DTD are declared as transitional just to keep the use of certain features such as link targets.

  43. Anonymous says:

    Brian,

    > "Transitional" and "Strict" are really misnomers in that these labels do not reflect the full scope of differences between the two DTDs.

    Transitional is intended for people transitioning from previous versions of HTML; Strict is more strict. I fail to see why you think they are misnomers.

    > Take link targets, for example; there is no equivalent offering in the Strict DTD to which one might transition.

    That’s why it’s called Strict and not Transitional.

    > Nor are so-called transitional documents ticking toward an expiration date

    Aren’t they? Suppose you started writing a browser today, or suppose you were maintaining a browser ten years from now. What are you going to put your effort into – <font> or CSS? How about the other deprecated stuff compared with modern practices?

    While the expiration date may be far off, it doesn’t mean it doesn’t exist.

    Future support isn’t the reason why you should avoid Transitional though, it’s simply that the kind of cruft Transitional was designed for hasn’t been necessary for years. If you are doing something that Transitional permits and Strict doesn’t, then at the very least, that’s a warning sign you should be aware of.

    The target attribute is one of very few exceptions, and it’s a minor one at that – frames are a terrible hack better accomplished through other means, and new windows can be opened with Javascript.

    > I would love to see a proper strict DTD that does not cripple functionality

    You are exaggerating wildly. Strict doesn’t "cripple functionality". Strict offers everything virtually all web developers need. There are occasional exceptions; not catering to these needs does not constitute being "crippled". In case you are not a native English speaker, "crippled" has a strong connotation of *major* systemic loss of functionality.

    You are also missing my point. The person advocating Transitional over Strict was doing so under the misconception that only Transitional was allowed to be labelled as text/html – surely you can agree that in this context, there really isn’t any need for Transitional?

    PS: more information on the "innerHTML isn’t allowed for XHTML" myth: the next version of Firefox will fix the bug that stopped it working in XHTML:

    https://bugzilla.mozilla.org/show_bug.cgi?id=155723

    It was just a Gecko bug, not forbidden by the specs.

  44. Anonymous says:

    "if we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs."

    Why not use the XML parser?

  45. Anonymous says:

    With xml prolog not switching into quirks mode, i hope there’ll be some way to switch box model by means of css. CSS3 box-sizing (or at least some -ie-box-sizing variant) would be more than nice.

  46. Anonymous says:

    Chris Wilson氏がXHTMLに関するドキュメントタイプやMIMEタイプについて記述していますね。( &#180;_ゝ`)フーン…って感じ。

  47. Anonymous says:

    XHTML renders beautifully (except for the CSS bugs) in IE when serving it as XML with a small XSLT hack. Is it really that hard to fix the bug that the XSLT hack fixes and treat XHTML as XML? Seriously, you guys need to look into it. Check this out: http://dean.edwards.name/my/application_xml.html

  48. Anonymous says:

    The XSLT hack is just a way to use the XML parser to pass the document tree to the HTML parser/renderer. CSS and DOM are applied to the resulting *HTML* document, and do not follow XHTML rules. This is very far from real XHTML support, which requires more complex interactions between the parser and the other components.

  49. Anonymous says:

    > > Strictly speaking, this is not correct – this only applies to the "XHTML 1.0 Transitional" document type [1] you MAY send as "text/html".

    >

    > This is wrong. You can send any XHTML 1.0 document that follows Appendix C as text/html. There’s no requirement that it be

    > XHTML 1.0 Transitional.

    No, just /read/ the Media Types note: http://www.w3.org/TR/xhtml-media-types/#summary

  50. Anonymous says:

    Jens,

    I have read that note. Quite a few times since it’s been published. It agrees with me, not you.

    Even if it didn’t agree with me, it’s a Note. The W3C doesn’t endorse it. The real thing you should be referring to is the text/html RFC. And guess what? That agrees with me too.

    Perhaps you are confusing "HTML compatible" with Transitional? When it says "HTML compatible", it’s referring to Appendix C of the XHTML 1.0 specification.

    If you don’t believe me, read section 3.1 of the article you are referring to. It quite clearly refers to Appendix C, not Transitional.

  51. Anonymous says:

    Something I’m curious about:

    You’ve said that you’re going to support CSS 2.1, when it goes to Rec status. Any word on CSS3 Selectors, which IIRC is also going to be going to Rec status around the same time?

  52. Anonymous says:

    "I’ve also been reading comments for some time in the IEBlog asking for support for the “application/xml+xhtml” MIME type in IE."

    If you are saying you want to do XHTML support correctly, then maybe you should first check your Media Type syntax:

    http://www.w3.org/TR/xhtml-media-types/#application-xhtml-xml

  53. Anonymous says:

    @Jens

    > No, just /read/ the Media Types note: http://www.w3.org/TR/xhtml-media-types/#summary

    And what we can read is:

    << XHTML 1.0 (HTML compatible) MAY be served as text/html >>

    A few lines above, we can find

    << [XHTML1] defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html. >>

    Whoops, would that mean that every XHTML1.0 currently existing may indeed be HTML 4.01 compatible?

    Ahoy, let’s set sails to the Appendix C of the XHTML 1.0 document…

    > C. HTML Compatibility Guidelines

    > This appendix is informative.

    > This appendix summarizes design guidelines for authors

    > who wish their XHTML documents to render on existing HTML user agents.

    There is _no_ mention of a specific DTD in Appendix C. The only thing that can be inferred from these documents is that ANY XHTML1.0 document following Appendix C’s guidelines MAY be served as text/html (even though it SHOULD be served as application/xhtml+xml REGARDLESS of it’s doctype.

    You are wrong, Jim is right

  54. Anonymous says:

    "The XSLT hack is just a way to use the XML parser to pass the document tree to the HTML parser/renderer. CSS and DOM are applied to the resulting *HTML* document, and do not follow XHTML rules. This is very far from real XHTML support, which requires more complex interactions between the parser and the other components."

    I guess that explains why I can use innerHTML that way and why it acts somewhat like HTML.

  55. Anonymous says:

    The decision not to implement proper support for the MIME type application/xml+xhtml is most disapointing. XHTML without the proper MIME type just isn’t all that it can be.

    Too late to reconsider, I suppose, eh? When’s IE8?

  56. Anonymous says:

    If you truly want XHTML to succeed in the long run, then you’ll do your utmost to see that IE supports XHTML’s registered, preferred and recommended ‘application/xhtml+xml’ MIME type ASAP. XHTML is HTML recast as XML. It’s preferred to use the XML DOM and parser to display XHTML pages, not the HTML DOM and renderer.

    http://www.w3.org/2003/01/xhtml-mimetype/

    Most XHTML 1.0 pages served as ‘text/html’ throw the backwards-compatibility guidelines to the wind. For instance, any XHTML 1.0 page using SIFR for graphical text will only work when served as ‘text/html’, not as ‘application/xhtml+xml’.

    http://www.w3.org/TR/xhtml1/#guidelines

    The longer IE allows this sort of XHTML bastardization to continue by not allowing the ‘application/xhtml+xml’ MIME type to engage its XML parser (IE7 does have MSXML, does it not?) the more prolific incorrect XHTML code becomes on the web. It seems to me that the best way to ensure the long-term success of XHTML is to support XHTML’s recommended MIME type, instead of encouraging sloppy XHTML practices.

  57. Anonymous says:

    @iEdML:

    "If you’re relying on quirks mode rendering, you shouldn’t be sending the DOCTYPE to any browser. Other browsers also distinguish between a strict compliance/standards mode and a quirks mode, so send it to quirks mode on all platforms."

    Place this script in the head of your valid XHTML or HTML document:

    &lt;script type="text/javascript"&rt;

    if (document.compatMode) {window.onload = quirk;

    function quirk() {if (document.compatMode != "CSS1Compat") alert("Quirks Mode");}}

    &lt;/script&rt;

    Now, remove the DOCTYPE. That’s right, Ffx renders in standards mode, IE and Opera go with quirks — there is no standard for DOCTYPE switching. If one needs quirks mode on all platforms, one must specify a quirky DOCTYPE.

  58. Anonymous says:

    Ah well, no support for Mime type application/xml+xhtml means that I for sure will shun MSIE 7.0. I hope that Firefox will ride the raising tide of usage — IMO it is by far the best Browser available.

  59. Anonymous says:

    I must add that I found the rationale put forth in rejecting adoption of the application/xml+xhtml Mime type for MSIE 7.0 to be the most horrendous gobbledygook (wordy and generally unintelligible jargon) I have encountered in some time.

  60. Anonymous says:

    Well, it’s nice to know at least some work by Microsoft is being done to *try* to actually conform to the W3C’s webstandards.

    Until then, I guess Internet Explorer users will just have to wait to view my website since I would rather not use any more server side scripting then I have to, especially when the reason is because of a browser’s lack of support for an open standard.

  61. Anonymous says:

    As somebody already quoted W3C Note on media type is realy clear : You have to support the application/xhtml+xml there is no way out for you.

    I see no reason for you not to support it but the fact you do not want other W3C XML specs things to be successfull and end up with hybrid documents embeding some SVG and MathML. So it is you choice …

    Either IE7 is realy XHTML full compatible, DOM2 full compatible (fully), CSS2.1 fully compatible and ECMAScript fully compatible (E4X anybody ?) or we will make our choice 😉

  62. Anonymous says:

    ‘Strictly speaking, this is not correct – this only applies to the "XHTML 1.0 Transitional" document type [1] you MAY send as "text/html".’

    The "HTML Compatible" part refers to XHTML code that can degrade to HTML with extremely little effort and without messing up the page. XHTML 1.0 code that can degrade to HTML should use "application/xhtml+xml", but it may use "text/html", "application/xml" or "text/xml". It is saying that any of these four media types are acceptable.

  63. Anonymous says:

    Oh my,

    IE7 won’t support the application/xhtml+xml MIME type?

    Hello! This is 2005!

  64. Anonymous says:

    Yikes II: 1.0.x are simply 1.0 with the new security patches applied. If you consider each of these updates a "new version", then every monthly security update for Internet Explorer is also an upgrade to a "new version". It’s the same exact thing.

    And as has been said, the update process will be a lot smoother in 1.5. The updates will come in patch form, like in Internet Explorer, rather than full installers.

    On a different note, what is the justification for only supporting a W3C standard once it hits REC? CR is defined as the stage in which browsers are supposed to start implementing it, and REC means that the feature is fairly well supported and web content authors are free to start using it. By not supporting the features at CR, all you’re doing is keeping it from reaching REC status.

    And back on topic, in the end, you shouldn’t make XHTML documents that are sent as text/html. The only benefits XHTML has over HTML are lost when you do this, and you might as well be using HTML 4.01 Strict. Just because you *can* send it as text/html doesn’t mean you should.

  65. Anonymous says:

    Will switching to alternate stylesheets be available? It really helps make sites more accessable by making seperate styles for different situations.

  66. Anonymous says:

    I don’t know if it’s a joke or a simple mistake but the appropriate MIME type for XHTML documents is not "application/xml+xhtml", but "application/xhtml+xml".

  67. Anonymous says:

    I know that Internet Explorer is still by far the dominant browser, but I find it continually surprising that computer science students still use IE by choice (or at least by default).  The course I teach requires students to produce XHTML, and even thou

  68. Anonymous says:

    junior college football recruiting