HTML5 Parsing in IE10


The Web is better when developers can use the same markup and same code across different browsers with the same results. The second platform preview of IE10 makes progress in this area by fully supporting the HTML5 parsing algorithm.

This continues work we started in previous releases to improve IE’s HTML parser to make more HTML “just work” in the same way across browsers. Some key examples include supporting SVG-in-HTML, supporting HTML5 semantic elements, preserving the structure of unknown elements, and improving whitespace handling. As a result of this work, most HTML parses the same across IE9 and other browsers.

Getting the right behavior

The goal of this work is to ensure all HTML parses the same across modern browsers. This is possible because HTML5 is the first version of HTML to fully define HTML parsing rules, down to the last edge case and error condition. Even if your markup is invalid, HTML5 still defines how to parse it and IE10 follows these rules. The examples below illustrate some cases fixed as part of these improvements.

HTML DOM ( HTML5 + IE10 ) DOM ( IE9 )
<b>1<i>2</b> |- <b>
  |- “1”
  |- <i>
    |- “2”
|- <b>
  |- “1”
  |- <i>
  |- “2”
|- <i>
<p>Test 1
<object>
  <p>Test 2
</object>
|- <p>
  |- “Test 1\n”
|- <object>
  |- “\n  “
  |- <p>
    |- “Test 2\n”
|- <p>
  |- “Test 1\n”
|- <object>
  |- “\n  “
|- <p>
  |- “Test 2\n”

Interoperable innerHTML

These improvements apply to innerHTML too. Code patterns like these now work as you’d expect in IE10:

var select = document.createElement(“select”);

select.innerHTML = “<option>one</option><option>two</option>”;

var table = document.createElement(“table”);

table.innerHTML = “<tr><td>one</td><td>two</td></tr>”;

Better error reporting for developers

HTML5 ensures markup will parse consistently. It’s still a good idea for developers to avoid writing invalid markup to begin with. Writing valid markup helps your site work the way you expect and is more compatible with older browsers.

To help developers with this, IE10 now reports HTML parsing errors via the F12 developer tools.

Screen shot of the F12 Developer Tools showing an HTML5 parsing error

Removing legacy features

Because some features in earlier versions of IE aren’t compatible with HTML5 parsing, we’ve removed them from IE10 mode. Sites that rely on these legacy features will still work when running in legacy modes. This way, sites that work today will continue to work with IE10 even if the developers of the site don’t have the time to update them.

Conditional Comments

<!–[if IE]>

This content is ignored in IE10 and other browsers.

In older versions of IE it renders as part of the page.

<![endif]–>

This means conditional comments can still be used, but will only target older versions of IE. If you need to distinguish between more recent browsers, use feature detection instead.

Element Behaviors

<html xmlns:my>

<?import namespace=”my” implementation=”my.htc”>

<my:element>

This parses as an unknown element in IE10 and other browsers.

In older versions of IE it binds to “my.htc”.

</my:element>

</html>

XML Data Islands

<xml>

This parses as <b>HTML</b> in IE10 and other browsers.

In older versions of IE it parses as XML.

</xml>

Your feedback welcome

We welcome your feedback making sure that all HTML parses consistently across browsers (including via innerHTML). Download the second platform preview of IE10, use it, and please report any bugs you find via Connect.

—Tony Ross, Program Manager, Internet Explorer


Comments (101)

  1. blake says:

    So. Flippin. Cool.

  2. M says:

    This is great news. Conditional comments, rest in peace.

  3. Jonas says:

    Thank you! IE 10 is shaping up real well!

  4. CompatMan says:

    Awful backwards compat support for conditional comments.  Did MS finally find out that developing their own standards for the web is a bad idea?  Use Gecko already.

  5. Isaac says:

    How do we deal with ie10 specific incompatibilities that will undoubtedly exist? Don't tell me javascript either, tell me what to do when I will NEED <!–[if IE 10]>?

  6. Roman says:

    Isaac, if you're using browser detection instead of feature detection you're shooting yourself in the foot and deserve to suffer.

  7. serpentatio says:

    Agree with CompatMan — don't get rid of conditional comments — they are very useful. Just keep innovating…Some of us just want to make good websites and don't really care about standards. Having a few branch statements is not a problem…we will have to do that anyway to use functions like requestAnimationFrame.

  8. Sami says:

    @Isaac: Use feature detection. It's right in the article with a link to more info on the practice.

  9. Aldonio says:

    I'm skeptical about IE10, since IE has never followed the standard by 100%, but its good to read that a good effort is being done :)

  10. Olivier says:

    @Roman and @Sami: that's not an answer ! How do we use features detection if we just want to use a CSS file only for IE9 and 10 ? And don't tell me to load it by javascript, it's ugly !

    Our websites works the same in every browsers (IE7,IE8,FF x,Chrome x,Safari x,Opera x and even IE6 with some limitations) and strangely, stuff doesn't appears the same in IE9 and 10. There are some texts which appears bigger, some elements aren't placed correctly.

  11. Donald says:

    @Olivier, using proper feature detection is ugly, but having a separate CSS file for each version of IE is pretty? Ummm, no.

  12. Alex says:

    @Olivier if that would be really the case(i _highly_ doubt it) then you would be either on the absolute bleeeeeding edge of all the technologie you are using(which again, i highly doubt) or you just suck at using HTML and CSS right. I (sadly) have to support IE7+ and the IE7 is the only browser that does some stupid ***, *sometimes* (css-wise)

  13. Sami says:

    @Olivier: What do you do if you want to use a stylesheet for any other specific version of a specific browser? Whatever that is, that's what you'll do for IE10 now. Doesn't that sound good to you? IE10 wants to be on par with the big boys, the other real browsers. If the IE team succeeds this will be a non-issue *just like it is for every other major browser*.

  14. Andrew Kolesnikov says:

    Here's to consistency!

  15. Mikael says:

    @Sami

    To this day, IE is the only browser that I've had to write conditional tests to load CSS for.

    If they remove that feature and the browser still has some quirks, then the situation will be worse than if they didn't remove them.

  16. Daniel Lopez says:

    Conditional comments are my favorite IE feature, they come in handy when you need to get dirty to fight against nasty IE bugs… but i guess we won't need them anymore because all future IE versions will be completely bug free…?

  17. Automatic updates says:

    I cringe every-time there is another IE version to support. If Windows did a better job including it with auto-updates, and you could install newer versions on older Windows, then I'd love it. But Windows XP is still a dominant OS, and the only way to have a decent browser is by NOT using IE, sigh.

  18. Oliver says:

    No conditional comments? Use feature detection? This is a great idea, especially if javascript is turned off. As long as IE is three years behind firefox/chrome and opera you should have kept them.

  19. Roman says:

    Oliver, do you want to say that you have never ever loaded different css for an old version of Firefox, Opera, Chrome? I think you're just bullshitting. There are known rendering bugs in all browsers regardless of name. With IE10 you'll just use the same technique you are using with the rest of the team.

  20. bobsaget says:

    about time.

  21. Ali Robertson says:

    IE10 will one day be a legacy browser. 10 Years from now this article will be cursed by all web developers. Your image will be burned in effigy again. Please, PLEASE DON'T DO THIS. Conditional comments are implemented for FORWARDS compatibility, not backwards compatibility. Chrome 10 and Firefox 3.4 are dead already, but you and I know that IE10 will still be deployed in 2020. I was so enjoying the fact that the IE team was actually being competitive, but yet again – Microsoft is shooting itself in the foot.

  22. Sushovan says:

    IE, please do not remove conditional comment support for IE10. While I know you have improvements to your interoperability, and your interest making 'same markup' across multiple browsers, the fact remains that any browser *will* have bugs. Conditional comments were a great way to work around those bugs. When *detecting* whether a feature is present or not, feature detection is the way to go, and educating web devs is the right thing to do. But for *working around* bugs, conditional comments are the way to go, and I would be very grateful if the IE team left us that option.

  23. Sushifox says:

    New levels of stupidity. Conditional comments are needed because YOUR browser has historically been the WORST out of ALL BROWSERS. IE10 is unlikely to change that. I genuinely despair.

  24. c69 says:

    Great news guys, great news!

    Special thanks for adding html parsing warnings and for having courage to leave conditional comments behind.

  25. alvatrus says:

    Great decision to remove the conditional comments.

    Just like enforing UAC was in Windows Vista, this will break bad coding patterns by force, with a load of cursing from the developers, who will be scrambling to adapt to the new landscape.

    But it is very much needed step forward towards a unified web across all browers. We have all been waiting for the day that IE is up to par with the other browsers (congrats IEteam, BTW), and now that that day has come we much take up the challenge and *do* write cross-browser, without falling back on old crutches.

  26. GM says:

    Welcome back to browser sniffing in order to have css classes like .ie6 …

    If you want to really change get ie10 working on XP and able to render ie6 specific sites from corporations…

    This way ie6 to 9 will be able to rest in peace and i will not have to test my developments for all ie versions…

  27. Gav says:

    This is great and everything… but I'll say it again… if you concentrated on fixing the trail of mess that is IE6/7/8 and 9 we would never have had to use conditional comments in the first place

  28. Oliver says:

    What score does IE10 get on  html5test.com URL?

  29. @Oliver – If the user has disabled JS, he/she already prefers he/she would probably be unable to use most of the HTML5 features, except for semantic tags, anyways. Thus falling back to a consistent basic interface should be more than sufficient.

  30. Jonathan says:

    But what if we have problems with IE10, in previous versions of IE the conditional stylesheets were our savior

  31. Ali says:

    Use webkit ffs, you've tried 10x and have yet to get it right. Just give up!

  32. GreLI says:

    How should I detect new possibilities in CSS? Such as Grid layout, etc. JavaScript detection doesn't fit, since we need to support users even without JS turned on. CC allowed to link to different CSS files to serve different browsers.

  33. leopld says:

    Fantastic news!

  34. Danny says:

    "The Web is better when developers can use the same markup and same code across different browsers with the same results."

    Strong evidence that this blog has been hacked.

  35. Joel says:

    Conditional comments make IE slightly more bearable. They need to stay.

    Also, Trident sucks, and probably always. IE, please just switch to WebKit like everyone else!

  36. Michael says:

    Not often I'll say this but +1 to Microsoft

  37. Igor says:

    Wow!

    Microsoft, you started to do a good browser!

  38. Andrew says:

    Hey – I got an idea… how about boycotting IE? I've already started using XHTML, so IE <= 8 can't view anymore.

    Genius, I know.

  39. E says:

    I develop in Firefox and then fix IE with conditional stylesheets. These stylesheets are getting shorter with newer versions. I even had a few projects where stylesheets >= IE8 were not needed at all. But as long as IE is using Trident, conditional stylesheets are useful, and in some cases, mission critical. Please leave conditionals as they are now. Thank you.

  40. Mike says:

    Leaving out conditional comments is a clear indication that IE10 will not _need_ it. So that should make us all happy.

  41. Jon z says:

    Bold move, I hope the future proves that IE10's standards-compliance is solid enough that the conditional code is no longer needed.

  42. well says:

    don't worry everyone! you may not be able to target and fix some IE10 stylesheet pain, but rest assured that since IE10 is only supported on a tiny percentage of deployed versions of Windows, you'll only have like 1% traffic from IE10 anyway! same thing happened with ie9, no one is using it! also you can get a job at a sexy new startup where they dont care about IE at all, graceful degradation they call it. brilliant stuff, keeps you motivated and happy to be a web developer. if all that fails – you suck too much to work at a startup, IE10 (or 9) comes into popular usage, etc – well, you can switch to iOS development instead where this stuff isn't a problem.

  43. Burkanov says:

    As for me, removing conditional comments matters not. Im setting on load body classes ".msie.vers_x_x" with javascript. But for those, that can't use js-based browser detection this promises a lot of pain. May be you should better let conditional comments stay? How should webdevs then write alternative CSS and, sometimes, DOM, to support IE?

  44. Mat Gilbert says:

    Dropping support for conditional comments is probably the worst idea ever. Why force developers to use an additional tool instead of letting them continue to use the existing paradigm for coding around your terrible browsers?

    As usual, Microsoft invents it's own way to do something different than everybody else. Thanks for taking a dump on my profession yet again.

    I would love to eat my own words and have IE10 play nice like Gecko/Webkit browsers… but as long as Microsoft has products in the market I'll have extra work to do to support your half baked broken implementations of the web browser. I still have to deal with IE6 and 7. What will I be complaining about with IE10 in 2 years?

  45. Allan says:

    Wouldn't need all of this if IE would make a decent browser to begin with. It's only IE that needs conditionals or feature detection. Seem silly to me that they can't. I only ever have problems with IE, even as I develop specifically in IE. FF, Safari, Chrome, Gecko, and don't seem to have the nagging and persistent issues. Why can't MS hold off till they actually have a good offering and leave it at that.

  46. mocax says:

    i've never used conditional nor browser sniffing nor feature detection. seem to get by pretty well….

    the only times i the browsers work differently are when i goofed (missing/extra end tags, missing semi-colons, extra commas etc). Chrome and FF seem rather forgiving of mistakes, which made me complacent….

  47. FremyCompany says:

    @IE Team: Will the so-called "Element Behaviors" be emulable with a "my|element { behavior: … }" property, at least ? HTML Components don't need to dispear, they need to be standardized. It's a completely different thing.

  48. willpeavy.com says:

    Great work on this IE team. I've used conditional comments extensively over the past decade, but I'm happy to see them go. The people complaining about conditional comment support being dropped are stuck in the past – it's time to update your way of thinking.

  49. AntiLuddite says:

    Why is this a problem? IE9 is incredibly standard compliant, and IE10 is even more. IE9/10 works perfectly with any website which can be viewed by Chrome, Opera etc. On the other hand NOBODY uses IE6/7 anymore (maybe around 5%). They can be safely ignored. On the other hand, IE9 is used by 12% of users within a few months of release.

    All in all this is a great move by Microsoft.

  50. Jswim says:

    Conditional Style sheets are the worst invention ever.  The only reason any developer uses them is because they are bull headed and don't care about history.  IE invented the DOM tree before there were standards and they are the biggest browser out there, so why shouldn't they fight to keep their "standards" the FIRST standards.  If you read up on the various rendering techniques and dom organization from the dawn of IE, you can write beautiful CSS that is cross browser supported w/o hacks and conditionals.  

    There was no point in conditional statements in the first place, except to satisfy all the lazy developers out there, and there is no point in them in the future.

  51. SnarkMaiden says:

    if conditional comments are gone in IE10 mode, does that mean setting the DOCTYPE to a legacy mode would make them still function in IE10 if a dev doesn't want to update a site?

  52. Brianary (the blacklisted?) [2 comments blocked] says:

    As you are catching up your CSS support, the other browsers aren't standing still.

    We'll still need conditional comments unless you can guarantee that IE10 will be on par with the AUTO-UPDATING browsers it'll be competing with in several years.

    @Jswim: That's not what "standards" means. One company in control has never been good. Get a few more years of development under your belt and you'll see what the difference between the browsers is!

  53. the_dees says:

    Tony,

    I wholeheartedly congratulate you on IE10, Preview 2. The HTML5 parser, the many cut offs of ancient limitations and cruft as well as a steady progress in standards support are making IE10 already a great browser.

    There are still some issues in parsing, DOM, CSS and other, see http://www.freewebs.com/…/iepp1 but it's really great to see so much progress.

    I'd also like to know if the proprietary -ms-behaviour CSS property will still exist in IE10. I'd prefer if it didn't exist there either, because the current level of HTML, DOM and CSS support eliminates their reason for existence.

    I hope you can focus on improving support of partially supported features in IE10 as well (Ruby, CSS inherit, all viewable on my list of tests).

    @GreLI: You do not detect new CSS features, you make your content fall back gracefully.

    @Mat Gilbert: CCs were the additional tool you speak of, IE10 can be handled like any other browser.

    @Anyone who would make MS use WebKit: Apparently you're shouting your critics at the wrong corporation. For a while, Apple's WebKit has been the worst out of the big four engines. They pass less than 90% of the CSS Test Suite (ok, maybe the crossed the 90% mark in the last few months), while other engines passed at least 95%.

    Take my list of testcases above, WebKit fails some tests other engines never had problems with in the first case.

    Also note that Safari 5 is currently the oldest browser labled the latest release of the big five.

    Go criticise Apply please, those people deserve it at least.

    @FremyCompany: Maybe XBL 2.0 can help you instead?

    And yes, comments evaluation seem to be very restrictive at the moment.

  54. Bill says:

    I have to congratulate MS for final getting on board with the 21 century.  I hope this means the end of MS proprietor codes.

  55. @anyone who thinks feature detection fills the bill 100% of the time, you are not a professional designer, pure and simple.  You may be a fine developer, but you don't test for design.

    @sukru-t, the idea that turning off JS means you don't want a properly styled page is ignorant.

    When a browser (this is not just IE, but Gecko and WK as well) "supports" a CSS feature, but renders it incorrectly, there is no way that feature detection helps you.  Generated content, hover states, rounded corners (to name a few) have all been "supported" by recent browsers, but the implementation botched so hard that they have to be turned off in initial "supporting" versions.  This will inevitably happen again.  CC made it easier to deal with in IE than elsewhere.  Now it's back to U-A guesswork for all browsers.  (Perhaps that centralization on U-A parsing could be considered a good thing so that CC can be revived in a standard at some point, but that's a reach.)

  56. Waldo says:

    Conditional comments are a great way to support multiple versions of Internet Explorer with the same codebase.  For Firefox, Chrome, etc. it's feasable to say "upgrade to the latest version", but with IE you know that's not the case.

    Please keep conditional comments for when we will be supporting IE versions 10, 11, and 12 simultaneously.  If they end up being a feature that nobody uses because nobody needs it anymore, *then* you can get rid of it.

  57. @AntiLuddite, it's telling that you left a li'l fella called IE8 out of your optimistic old days/new days conclusion!  I too have no great worries about IE 6 and 7 anymore, as those were the really bad old days (in terms of the sheer number of rendering issues, not necessarily the importance of each).  But that's not the point.  The point is that *all modern browsers* (not just Trident-based) still introduce so-called "support" for new standards that is in fact broken and unuseable.  DOMImpl reflection is not going to tell you "Oh yeah, I support that nutty new <style/pseudo>.  I render it totally <offscreen/jaggy/offset/otherwise wrong>, so don't use it, though."

    So if you want to use styles only where they actually render correctly, you have to be prepared to do browser detection, either server-side or client-side.  This means guessing based on the U-A (people who change their U-A to something "l33t" can have a ball with that, whatever).  Although I think CCs' ability to do non-JS client-side detection was a cool thing, I'm largely okay with EOL'ing conditional comments.  Just as long as people stop spreading this FUD that feature detection takes its place.  It doesn't. It means we have to do more work in script/backend to get styles right. Experienced designers already know this: even if it "felt wrong" to browser-detect a broken version of Safari, so you changed the design instead, you know the only way you *could have* made it work was by checking for version "A.Broken" and styling/destyling accordingly.  (Luckily, I control my servers as well, so I can avoid relying on JS, but I feel worse for people who only do UI.)

  58. Evan says:

    I think the flaw here is this: it would make sense to use feature detection if browsers were equally likely to stray from standards. Now, let's face the reality: IE browsers stray from standards FAR MORE OFTEN than any other browser. And, to make matters worse, each new version of IE strays from standards in its own frustratingly unique way. And to tell developers to "detect features" is like telling a bystander on the street that he/she should only distrust a convicted felon if that felon is wielding a lethal weapon.

  59. hAl says:

    @Evan

    IE is currently much more conforming to standards than other browsers.

    CSS 2.1 : test.csswg.org/…/results.html

    Javascript: http://test262.ecmascript.org/

  60. Alex says:

    Good Lord!!! Why does nobody see that the release-cycle of ie switched from "when we feel like it" to, "every year with major accomplishments" there will be no cc anymore – why? cause there not useful anymore.because the basic support of HTML5 and especially CSS3 will be done with this iteration. So stop you f*ckin whining! Think before you talk/type.

  61. AndyC says:

    Shouldn't all those complaining about the removal of Conditional Comments be petitioning the w3c to have them added to the standard, if they need them so badly? It hilarious to see people simultaneously complaining that IE doesn't follow standards (despite it now being the most compliant) and also requesting a non-standard HTML feature be left in.

    P.S. WTF is it with the MSDN blogs software that seems to break in IE9. Talk about shooting yourself in the foot.

  62. Mitch 74 says:

    Removing support for conditional comments is a good thing, inasmuch as it ensures that websites coded using [if IE] don't load fixes that don't apply in Strict mode : I guess that this isn't so much about CSS, but more about people loading some scripts for all browsers, and then adding a compatibility layer for IE only.

    For those that didn't follow: conditional comments are NOT disabled altogether, they're just not supported for versions 10 and above. In IE9's case, stuff like text-shadow meant that you could still need an alternate stylesheet even with a valid Strict mode webpage, but if IE10 includes ALL CSS 2.1 (after all, it IS now final) and implements all CSS 3 proposals, then CCs are not needed for CSS anymore; that leaves script, and in that area, I think that finally including a proper DOM model, a proper parser and a compliant event model will solve pretty much all these problems.

    @IE team: please ensure that convoluted syntaxes that allow CCs to EXCLUDE IE are properly parsed.

  63. Yahooo says:

    GTFO! Microsoft finally supports proper HTML parsing and even fixed the .innerHTML setter on select and table elements!

    removing behaviors – wow about time!

    removing conditional comments – at first I was gah! but then I realized from IE10 onwards, we don't need them – IE is actually capable!

    removing XML data islands – thank god! this was a disastrous plague that infected many enterprise applications. I will not be shedding any tears over this decision.

    one last thing – why on IE10 a browser that only runs in Windows 7, is the dev tools window sporting 1995 style toggle buttons? surely someone can take 5 minutes to update the skin on these elements so that IE's dev tools look worthy of using?

  64. Yahooo says:

    interesting… links in IE10 that open in a new window open in my default browser (Chrome).  On the one hand (+1) for actually following my settings, but if I'm in IE10 to test – wouldn't I want to open the window in an IE10 frame?

  65. FremyCompany says:

    @the_dees : XBL don't seems to allow you to isolate your DOM from the original document the way the HTML Components does. I would use it if it would be a de facto standards, but at this time it's not widely supported. If I still can have an impact on the future standards, I would say that I prefer something closer to HTC than to XBL. HTC is supported in IE5+ and has been proposed for standardization a long time ago and I don't understand why it wasn't. There must be a reason, though.

    As a note, the SHADOW DOM from HTC is the only thing that allowed me to sucesfully implement the PROGRESS and METER in IE9, and it's probably the only thing that will allow you to skin properly an input[type=file] or a scrollbar when standardized.

  66. FremyCompany says:

    @the_dees : Sorry, it seems XBL actually supports Shadow DOM. The specification is quite complex but I must agree it fulfills my needs. The problem I have is that I don't see this implemented in IE10, sadly…

  67. Paul Comanici (darkyndy) says:

    I cannot stop to be amazed on how IE destroys web development.

    As usual IE10 will be released will have enough bugs, will have incomplete support or not at all for some feature and by removing conditional for IE then we will add overload for real browsers.

    So "IE10 may live" will become soon "IE10 must die".

  68. Brent says:

    "The Web is better when developers can use the same markup and same code across different browsers with the same results."

    Maybe the developers of the IE10 team can help achieve the above goal by supporting CSS3 properties such as text-shadow? Just a thought.

  69. yellowstone says:

    IE10 .jxr(JPEGXR) image file support.

  70. willpeavy says:

    @Weezy -

    "The point is that *all modern browsers* (not just Trident-based) still introduce so-called "support" for new standards that is in fact broken and unuseable."

    Are you talking about cutting-edge stuff or established standards? Can you provide an example of some valid HTML4 + CSS2 that fails in the latest stable release of the major browsers?

  71. Mark A in the UK says:

    I would still like to have a command like <!–[if IE]> or <!–[if IE10]>

    We could use the userAgent by searching for "MSIE 10.0;" but only if Java Script is enabled. :o(

    PS. You can't post messages with this form using IE9 or IE 10.

  72. Andreas Mertens says:

    Just an idea around the HTML error reporting in the F12 developer tool: It's great that this is here. But would it be possible to expose as an API so that other dev tools can also integrate this error reporting?

  73. Jackson says:

    Out of all of IE10 new features where the hell is the built-in Spell Checker that are on most newer web browsers these days Microsoft IE team.

  74. Bunbundoolooey says:

    Too late. Do you know how many developers have already died before seeing this? And even this is just a vaporware claim, one we've heard before. 30 years of pathetic security, more than enough billions to just fix it, spend more on marketing lies than SEs, should tell you something.

  75. Lance says:

    Best Post Ever

  76. Steve says:

    Congrats on finally fixing your 15 year old .innerHTML bugs with: Table, THead, TBody, TFoot, Tr, Select, Optgroup, etc.

    Is this therefore also fixed on the HTML and HEAD elements? – please confirm the status on this.

  77. jader3rd says:

    @Jackson, Just use an add-in for spell check.

    @Mark A in the UK, I'm posting this comment with IE 9.

  78. Jason says:

    Please, follow Netscape and just stop trying already. Your browser is so far behind everyone else and let's not talk about security…

  79. Jared says:

    I'm not sure why everyone is so excited about the removal of conditional statements?  Unfortunately, IE has had too many quirks in the past that cause elements to not display as they should, even when using completely valid HTML.  It is certainly better to use the conditionals for IE than it is to write some cryptic hacks or use feature detection due to the fact that just because IE may support the feature does not mean that it does it correctly.

  80. Mark A in the UK says:

    @jader3rd

    Testing.

    Posted this using IE9.

    Tested using an Internet Explorer 9 clone browser (AOL using IE9) and it didn't work with Windows 7

    Tested with IE10 Platform Preview 2 (10.0.1008.16421) and it didn't post.

    Tested with Internet Explorer 9, OK

    Surprised that the msdn.com blog dosen't support Internet Explorer.

  81. Bj says:

    Let's see if removing CC will cause people to sniff using JS before and dynamically inserting CSS, I hope not, but "web devs" often seem to have a kind-of "whatever works" atidute.

  82. Andrew says:

    I find it funny that, even though Microsoft does not support browser dectection (which is obvious through a few blog posts here – this one and another one regarding cross-browser feature detection) they still use it themselves.

    I visited the new Hotmail today in SeaMonkey and I got an XML error. However, it worked fine in IE9. So, obviously IE9 is either not parsing the XML properly and letting the errors through, or Hotmail is serving IE9 HTML (and not XML).

    If Microsoft is dropping browser detection through markup in Internet Explorer 10 then I would at least like to see them stop using browser detection throughout their services, such as Hotmail. Otherwise this proves the need for browser detection.

  83. Björn says:

    The following from the MSDN page on XML Data Islands made me giggle:

    "The W3C expects to evolve the HTML specification to include the capability of embedding XML in HTML documents."

    Oh boy…

  84. the_dees says:

    @Björn:

    In case you didn't notice. That expectation is as old as the XML Data Islands feature itself (1998) and has since been ignored and obsoleted by HTML 5.0 :-)

  85. DanglingPointer says:

    From ieblog: "Even if your markup is invalid, HTML5 still defines how to parse it and IE10 follows these rules. The examples below illustrate some cases fixed as part of these improvements."

    Quick questions:

    1) Using <form> inside <table> isn't a standard HTML. But IE supports it and submits the form with no probs. FF never liked it in the past. Then FF4 incorporated tolerance for it. Is it a good thing? Tolerating non-standard?

    2) Next, in my ruby-on-rails app, using prototype I was binding the new input fields on-the-fly (with the said configuration of mark up). In IE its submitting those dynamic fields properly (means full-support for wrong markup), while FF was not submitting the "dynamic fields" — that were specifically linked with prototype at clientside and/or those which were fetched remotely from the ajax — means partial support for wrong markup. Which one is better and why?

    I was debating with FF guy at FF's IRC that not tolerating the "whole wrong" is wrong. Either you are handling the scenario as a whole or you are denying taking care of it. It looks like an unfinished work done from FF guys.

    ——————————————————————————————————————————————————-

    @ieblog, I have three little suggestions for IE10 — GUI related —

    1) Ctrl+[pressing back button] should open the prev link in new tab.

    2) "Create download" in (Ctrl+J) download manager, so for example I can manually enter the pdf link and download within its window.

    3) Again in download manager, show download progress in bytes as well for the active download (it could be in the braces after downloaded% — once your deliver this, I would instantly uninstall FDM from my system).

  86. Shafted Again says:

    What a crock! I just went through my test suite in IE10 – the supposed "Fix" for the decade old SELECT.innerHTML bug IS NOT FIXED AT ALL!

    Tested in IE10 Platform Preview 2 – all 12 SelectElement tests failed!

    Not impressed.

    PS your comment form is pathetic! This is my 3rd attempt to post! (with all comment data lost – please for the love of god get off of community server – it simply is NOT reliable!)

  87. Shafted Again says:

    your comment form is almost as bad as your SelectElement.innerHTML implementation.

    You set the innerHTML… and not only does it not add the options you wanted, but it erases the ones you had!

    while you are fixing this bug for real, please also fix the bug with SelectElement whereby you can't modify the contents of the Select (using any technique) in a click or focus event on the select (e.g. lazy loading) because IE also has a bug that the select element auto-closes if you attempt to change any of the sub-content.

  88. ieblog says:

    @Shafted Again: Are you sure your test suite is running in IE10 document mode? If not, the bugs will still exist. The HTML5 parser applies to 10 standards mode only.

    If you share a link to the tests, we'll be happy to take a look.

  89. @ieblog about this comment form says:

    I agree with Shafted Again, if the person is not signed-in and manually entering the name and trying to post a comment, *sometimes* the comment gets lost and is never shown and page gets refresh while losing the comment post (that’s why I save a backup of my post in notepad before submitting a comment on msdn) I am able to reproduce this clumsy bug/error/disaster on FF5&6 and IE9.0.1.

    Don't you know about it? Is it really something new for you? Are you surprised by listening to this issue? I don’t think so. I have seen atleast 10 comments in various blogs post here in MSDN'sIEBlogs about the same issue. I believe you guys do it deliberately, as I cannot believe that you guys are so dumb! Consequently, I am compelled to believe this way: Like MS don't provide spellchecker in IE because they want to promote MSWord. Similarly, MS doesn't provide a decent blogging system to promote their Notepad app.

  90. Steve says:

    @ieblog – I too have re-tested the .innerHTML on Select elements in IE10 in full Standards mode, IE10 document mode etc.

    It is MOST DEFINITELY STILL BROKEN!

    try creating a select with some options, read them in, append to them and set again… you will have ZERO options (all are wiped out)

  91. Tony Ross [MSFT] says:

    @Steve:

    Can you share a link to your test case? I've looked at a number of combinations along the lines of what you suggested and all of them appear to work. You can find them here if you want to run them for yourself: ieblog.members.winisp.net/…/selecttest.html

    Also, make sure you're using the second platform preview of IE10. The first platform preview of IE10 does not have the HTML5 parser.

  92. Mark says:

    @Tony Ross [MSFT]

    here is the test for innerHTML performance, jsperf.com/options-add-vs-innerhtml you can see Safari is outperforming all the browsers including IE10pp2! You need to improve the index, insert and remove operations on DOM nontroppo.org/…/Hixie_DOM.html <- as it seems interlinked to the pervious test. These operations really need improvements.

  93. Mark says:

    For the record in this DOM manuplation test: nontroppo.org/…/Hixie_DOM.html

    Time taken to accomplish this test

    Safari 5.0.5: 172ms,

    Chrome 12: 319ms

    IE9: 44430ms !!!!!!!!!!!!!!!!!!!

    IE10pp2: 41185ms !!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    WHERE IS THE PERFORMANCE GOING IETEAM :(

    IE10pp3 should complete in 100ms that would be a *significant-breakthrough* for the world :)

  94. the_dees says:

    @Mark:

    The jsperf Tests performs equally well on my machine using either Firefox or IE10, Peview 2.

    The nontroppo tests performs worse. Can you tell me the bug number of your Connect report, please?

  95. Andrew says:

    @the_dees,

    I get similar results to Mark for IE9.

    IE9: 16575ms

    Gecko: 400ms

    Of course I can't test IE10 because I am running Windows Vista. ;)

  96. Steve says:

    @Tony Ross[MSFT] – I'm pretty sure I have all the correct settings and am running platform 2 of IE10 Alpha.

    here's a screenshot of the IE10 failure on the test page you've listed.

    img41.imageshack.us/…/ie10pp2selectfail.png

    I see similar results in all my tests.

  97. Steve says:

    hmm – it looks like my install is corrupted – better yet, trying to install it again fails with the following message:

    Installer error 2803.

    I'm going to try uninstalling the PP and re-installing it. If that fails I give up.  I've waited 15 years for this bug fix – I'm sure a few more months/years won't kill me.

  98. Tony Ross [MSFT] says:

    @Steve

    Thanks for the update. The build number in your screenshot, 2.10.1000.16394, indicates you are running platform preview 1. The build number for platform preview 2 is 2.10.1008.16421.

    I'm not sure what would be causing the installer error you're seeing. Let me know if uninstalling then re-installing works for you.

  99. ernest meyer says:

    This is why less than 5% of all people visiting my site use IE any more. They are fed up with these addings and removings of features so half the pages they visit don't work like they used to.

    And now it includes me. For example I add HTML5, but of the 5% of people on IE who visit my page, half of them are still on IE8. So I have to force IE9 emulation. Good bye IE developers, it was fun while it lasted. bill Gates really lost on this one and Brehmer only made it worse. Brehmer deserves to be roasted like the self-conceited obnoxious pig he is.

  100. neil says:

    oh my god I hate IE, I am glad that 10/11 are more functionable than lt10 but they are still terrible and the conditionals were a convenient way around most the things wrong with IE. Please stop making IE entirely and let better browsers do it, there are plenty of them and more people are using the competition now than ever, admit defeat please STOP!