HTML and DOM Standards Compliance in IE8 Beta 1

With the release of IE8 Beta 1, I'm pleased to be able to talk about the first round of improved standards compliance and bug fixes in IE's HTML and DOM support for the new IE8 standards mode. Doug hinted at some of these improvements, and I wrote a little bit about them in the IE8 Beta 1 whitepapers here and here. In this post, I'd like to enumerate the 'change list' (of sorts) here on the blog in response to requests for such a list that I received at MIX08. Personally, I've been long-awaiting this release because of what I know it means to web developers (like myself) that have had to code around a lot of IE's DOM quirks for many years.

For IE8, I have really focused on the HTML and DOM Core standards and concentrated on building a solid cross-browser compatible foundation for many of the APIs that are already supported by Trident. This effort to fix some of the cracks in IE's foundation has been a long time in coming, and I believe it's a critical and necessary first step before adding on additional standards support.

For IE8 Beta1, we looked at many community-provided bug reports and found that the top pain-points were related to IE's attribute handling (with a few prominent exceptions like getElementById). Therefore, attribute-handling has served as the 'theme' for the set of issues to tackle in IE8. We probably won't be able to fix all of the community-reported bugs in the DOM in this release (there are many), but we want to make sure that we get to the worst offenders first. Help us out by submitting or voting on the bugs that you feel are most impactful to your business.

HTML/DOM Standards Compliance in IE8 Beta 1

Note: I use HTML5 nomenclature for DOM attribute/content attribute.

Big-impact improvements in Beta 1

Within the scope of attribute-related fixes, the following address some of the well-known, oft-cited, compliance issues in IE's HTML and DOM support.

  1. <BUTTON> type attribute defaults to 'submit' rather than 'button' in IE8 standards mode.
  2. setAttribute now uses the content attribute name (rather than the DOM attribute name) for applying an attribute value (also camelCase no longer required).
    • This fixes the commonly reported issues regarding the 'style', 'class', and 'for' attributes not working.
  3. getElementById finds only elements with matching id (not name) and performs case-sensitive matching.
  4. <BUTTON> value attribute text now submitted iin form submit in IE8 standards mode. IE7 standards mode continues to submit the innerText.
  5. <OBJECT> now supports native image loading (see the whitepaper for more details).
  6. <OBJECT> now supports fallback for two additional scenarios: HTML embedding and native image loading (where the HTML/image resource cannot be loaded, i.e., 4xx-5xx HTTP response codes. ActiveX controls still do not support fallback (see the whitepaper for more details).
  7. URL-type DOM attributes separated from content attributes. For example: <A>.href (DOM attribute) != <A>.getAttribute('href') (content attribute). You will find that all URL-type DOM attributes return an absolute URL, while the content attribute returns the string that was provided in the source. These changes apply to the Attr.value and getAttributeNode as well. Specifically:
    • The following element's DOM attributes now return absolute URLs: applet [codebase], base [href], body [background], del [cite], form [action], frame [src, longdesc], head [profile], iframe [src, longdesc], img [longdesc], ins [cite], link [href], object [codebase, data], q [cite], script [src].
    • The following element's content attributes now return relative URLs: a [href], area [href], img [src], input [src].
Consistency and reliability with Standards and other browsers (attribute-related) in Beta 1

Many reported (and some not-reported) issues with IE's attribute handling involve the NamedNodeMap interface object (object.attributes), correct DOM attribute reflection of content attributes, and case-sensitivity. In principle, the standards indicate that HTML documents are case-insensitive, while DOM Core-related APIs are case-sensing--they depend on the underlying document rules to determine their sensitivity. To resolve ambiguities, I appealed to the most common behavior of other browsers.

  1. <element>.attributes.getNamedItem no longer creates Attr objects that don't exist in the collection (returns null when an attribute is not found).
  2. Radio button fixes:
    • Dynamically setting the 'name' attribute on a radio button now correctly applies that radio to same named group (old known-issue fixed in Quirks, IE7, and IE8 standards modes).
    • Radio buttons without a name attribute can now be selected by the user in IE8 standards mode (I found it interesting that the code revealed this to be an old Netscape compatibility issue).
  3. <FORM> enctype DOM attribute now supported. Reflects the enctype content attribute.
  4. Checkbox fixes:
    • Inserting checkboxes into the tree (and moving them around the document) no longer resets the 'checked' state with the 'defaultChecked' state.
    • The 'defaultChecked' DOM attribute now reflects the 'checked' content attribute. The 'checked' DOM attribute affects both the intrinsic behavior on screen and the form's submitted value.
    • Parsing operations on the 'checked' content attribute always affect both the 'checked' and 'defaultChecked' DOM attributes. (For example, removeAttribute('checked') sets 'checked' and 'defaultChecked' to false, setAttribute('checked', 'checked') sets both DOM attributes to true (as if the element were being re-parsed).
  5. getAttributeNode now correctly populates the .value property of the returned Attr object for all attributes (whether .specified=true or not).
  6. removeAttribute now uses case-insensitive comparisons.
  7. <P> element now closes when <TABLE> is encountered (ACID 2 compliance).
  8. <LINK> rel content attribute now finds 'alternate' token in any location in the string (ACID 2 compliance).
Additional compliance and feature completion in Beta 1
  1. <BASE> href no longer applies a 'new' document base if the supplied URL is a relative URL (relative URL being defined as not having a schema ['http:'] and a hostname ['/' or 'domain']).
  2. Title attribute now preferred (over alt) when specified as the popup tooltip for images and maps (img, input, object, and area elements).
  3. When retrieving Boolean attributes by name, the value is now correctly reported as the canonical attribute name (e.g., checked='checked').
  4. Implemented hasAttribute (case insensitive matching) which is the suggested workaround while the NamedNodeMap is under construction.
  5. Completed the Attr interface (of DOM L2 Core) by implementing ownerElement.
  6. Completed the interfaces for object, iframe, and frame (DOM L2 HTML), by implementing contentDocument. Note: like contentWindow, this property will not allow cross-domain access to the inner content.
  7. HTMLCollection fixes:
    • 'item' API is no longer overloaded to accept strings and act like 'namedItem'. 'item' now only accepts numerical indexes (or tries to convert a string to a numerical index as is JavaScript behavior).
    • 'namedItem' no longer returns collections if more than one named item is found. Instead, the first matching (case-insensitive) element is returned.
    • As IE8 does not implement all collections using the HTMLCollection interface, the following exceptions currently exist: elements [HTMLFormElement], rows/tbodies [HTMLTableElement], rows [HTMLTableSectionElement], and cells [HTMLTableRowElement].

Known Issues

A significant bug in our JavaScript invoke code path in IE8 Beta 1, causes some JavaScript calls to inadvertently revert to IE7 compatibility mode and therefore make it appear as if some of the aforementioned bugs are not actually fixed. 🙁 This has personally affected some of my tests that pass DOM objects (like HTMLCollections) through a function parameter for testing--I mention this only by way of example. While you will see this bug fixed in Beta2, it may indirectly impact your own testing--I recommend checking for the existence of document.querySelector to see if your script execution has reverted to IE7 compatibility mode before concluding that IE8 Beta1 has not fixed a particular bug (the Selectors API is only visible to IE8 standards mode).

Known issues we are planning to address in Beta 2

At a minimum, all previously available functionality in the DOM will be restored in Beta 2.

  1. setAttribute still does not work with event handlers.
  2. <element>.attributes.length fails. The IE8 NamedNodeMap object is in the middle of an overhaul.
  3. Many TABLE-related API are 'not implemented' as of Beta1. As critical pieces of the IE8 layout engine come online, these APIs are being re-enabled:
    • rows/tbodies [HTMLTableElement], rows [HTMLTableSectionElement], cells [HTMLTableRowElement].
  4. <OBJECT> elements don't fall back on cross-domain security failures.
Known issues we are not planning to change in IE8
  1. <OBJECT> is not parsed in a cross-browser compatible way (parsing stops at the OBJECT, whereas other browsers continue parsing all the fallback content and make it available. No support for this parsing behavior is planned for IE8; I'll take this opportunity to ask for real-world scenarios that can help me prioritize this feature.
  2. <OBJECT> elements cannot be 'reactivated' by dynamically correcting the attributes that caused the original fallback. Again, your feedback on the potential benefits/use-cases for this feature appreciated.


I'd like to acknowledge the amazing work done by all the IE developers and testers that make it possible to push a button and get IE7 compatible behavior for each of these significant changes.

Also, special thanks to PPK for updating his compatibility tables to showcase some of the work that we've done.

And there's more to come.


Travis Leithead
Program Manager
IE8 Object Model

Comments (85)

  1. first bug in your post says:

    all your tag names should are belong .toLowerCase();

  2. Harvey says:

    Your .getElementById( id ) as reported by many across the Net still has issues in IE8.  There is also a bug registered in IE Feedback with a test case URL, that needs to be confirmed by Microsoft.

    I thought that in IE8 you were taking bugs seriously now? even though you don’t let everyone participate.

  3. Chris says:

    setAttribute(‘style’,’css string’);

    Still fails in IE8 Beta 1:

  4. oliver says:

    The biggest thing missing in IE is the ability to properly prototype on Elements or even HTMLElements.

    Because they are not native JavaScript objects we can’t properly extend things – or more importantly – fix stuff that Microsoft doesn’t.

    I would love to prototype fixes for IE only for the following:




    But all of these require the ability to prototype on Element.

    Why do we want this? Easy! .setAttribute() is still not fixed (style, onclick, onthis, onthat), setting the .innerHTML of various elements still barfs (select, table, etc.) and getElementsByName() would be really handy, if it actually worked in IE.

    I would sure love to believe that all of this will be fixed in IE8, but we expected all this mess to be fixed in IE7 and were sadly disapointed.

    Please, Please, Please! Prioritize Element prototyping so that IE8 will be a competent browser.  I’m tired of a massively degraded experience in IE because it isn’t on par with any other browser out there.

  5. Travis [MSFT] says:

    @first bug in your post

    Great compat issue. File this if you haven’t already 🙂

    @Harvey, I’ll take a look. Thanks for the feedback.

    @Chris, Pardon the non-validating code, but this worked for me on the Beta 1 build:




    &lt;script type=&quot;text/javascript&quot;&gt;

    document.write(&quot;IE mode= &quot; + document.documentMode);

    document.getElementsByTagName(&quot;div&quot;)[0].setAttribute(&quot;style&quot;, &quot;border:2px solid #ff0000;color:#00ff00;&quot;);



    @oliver, I’ve heard this request from many influential sources as well, we (myself personally, and the IE team) recognize that this is a priority for the web development community at large. We are taking this feedback very seriously.

  6. "Therefore, attribute-handling has served as the ‘theme’ for the set of issues to tackle in IE8."

    Does this mean that we can expect no further improvements in IE8 for DOM support outside of ‘attribute-handling’ ?  What about full DOM Level 2? DOM Events?  Or do I have to wait another two years?

  7. Damon says:

    Here are my votes:

    – DOM prototyping (as previously mentioned)

    – DOM2 Events

    – proper support for application/xhtml+xml content-type and have it listed in http_accept header

    Also, I too am still having problems with getElementById().

  8. Garry Trinder says:

    You guys are awesome, thanks!

    One thing you might want to look into is why the official Silverlight forums continually bomb out IE8 in Emulate IE7 mode.

  9. Greg says:

    @Travis [MSFT]

    Regarding "style", try setting it on a select element, it won’t work.

    and trying to retrieve it from a select element returns an [object] not a string of CSS property/values.

    This bug is well known in the dev community in IE8 Beta 1.

  10. Greg says:

    @Travis [MSFT]

    This also fails on ‘cellpadding’ and ‘cellspacing’ on table elements.

  11. cico says:

    What about the support for the <q> element?

  12. Mike says:


    you guys are awesome


  13. Please, do not show alt as tooltip in IE8 Standard Mode. title attribute can be used for tooltip instead.

  14. Dave says:

    Good news on the handling of <button>. It’s really great to see the direction IE8 is headed, keep up the good work!

  15. Olly says:

    @oliver — I was under the impression that .setAttribute() wasn’t supposed to work for events (i.e. onclick, onthis, onthat)? Events  aren’t actually attributes as such.

    You should of course feel free to shoot me down if I’m wrong on this 🙂

  16. Aaargh! says:

    Don’t bother releasing IE8 until it passes Acid3.

    Actually, I don’t get why you guys keep working on Trident, it’s outdated and broken and it’s a waste of time. There are several great and more importantly: crossplatform, engines out there, like e.g. WebKit and Gecko.

    Just take a look at Pocket IE, it’s a joke compared to e.g. Nokia’s series 60 browser (which uses WebKit) and it clearly is a different render engine than IE/Win32, which sucks because PocketIE users won’t benefit from improvements in IE8.

    PLEASE switch IE to WebKit or Gecko, you can keep Trident around for the IE6/7 compatibility mode.

  17. vtondrjc says:

    Refer: 7. <P> element now closes when <TABLE> is encountered

    Bug: <div> element should be closed when </body> or </html> or end-of-document is encountered.

    At the moment an ". . Internet Explorer is unable to load this page . . " error message and a totally inappropriate error action results when the last div in a document body does not have a </div> The action is the same as when a page cannot be loaded at all (even after parts  of the page may already have been rendered)

    What makes finding the html bug difficult is that the problem is not absolutely repeatable. Sometimes when changes are made to the html the rendering bug disappears, only to reappear when other html changes are subsequently made.

  18. I can’t go too far with DOM related stuff as frankly IE correctly functions with the JavaScript that *I* know how to program (which isn’t very advanced). So I’ll try to stay as on topic as I can here…

    I’d like to see support for disabled form elements.

    Also after a bit of reprogramming on my site I’ve made it so you can single click to get to test out a weird bug in IE. This link enables DHTML on my site and will open a "prompt" (layer). The DHTML engine (jQuery) will allow you to drag the prompt around like a restored sized window (not maximized/minimized, say like the display properties control panel window). Drag the prompt by it’s header (the top purple bar essentially). The bug occurs when you let go of the button and the prompt incorrectly positions itself at the top-left. Again I’m not close to being JavaScript guru so what sort of DOM issue this may be related to I could only vaguely place my guess on position/absolute combined with static dimensions (my site is viewable @ 800×600). Here is the link…

    It seems you folks have been busy cleaning up a lot of Homer Simpson Angry Dad neck bump issues, good job! 🙂

  19. Damon says:

    Not sure if this has been addressed yet for IE8…

    Even though innerHTML is not a standard, how about full read and "WRITE" support for innerHTML on "ALL" table elements.  Currently the TABLE, TBODY, TFOOT, THEAD, TR elements are read-only.

  20. Jim says:

    I can’t believe there’s still no mention of standard DOM event handlers.

    Is this being planned for Internet Explorer 8 or not?

  21. anphanax says:

    "Just take a look at Pocket IE, it’s a joke compared to e.g. Nokia’s series 60 browser"

    Your complaints are directed at the wrong team. I believe is responsible for IE Mobile and Pocket IE.

    "more importantly: crossplatform"

    I don’t think they care if it’s cross-platform or not. If it’s Windows-only that allows them to optimize it for a single platform.

  22. night says:

    Great work so far with IE8, you must have a huge workload. I’m glad it’s not me who’s having to prioritise everything.

    @ [MSFT] – Maybe have to be IE9 now, but can you *please* look at how IE renders floated lists compared to other browsers? One of the biggest obstacles to switching to table-free layouts (to meet WCAG standards) is that it’s unbelievably hard to make floated lists look the same in everyone’s browser. This is particularly important because floated lists *are* the way to do table-less navigation.

    Anyway, that’s another one to add to the list 🙂 If you’d like me to pop together an example of the problem just reply in a later comment.

    Keep up the good work!

  23. Brian Fink says:

    Thanks for fixing the bug with the ordered list inside position! It renders perfectly in Beta 1. Keep up the good work! When it wasn’t fixed in 7, I thought you had forgotten about it. Again, thank you! Now there’s one bug less that I have to code around!

  24. Blaise Kal says:

    I’m glad that Internet Explorer is evolving, but I’m worried about the gap with Opera, Safari and Firefox. IE8 is nowhere near these browser in terms of standards support and number of bugs. Will this gap ever be closed?

  25. Brian Fink says:

    The Conditional Comment Tag in IE8 beta 1 does not work properly. It excludes a block of code ONLY if the tag says [IF !IE] and it ignores false conditions otherwise. Examples of values I have tried are

    [IF lte IE7]

    [IF lt IE8]

    [IF !IE8]

    The result is that a patch for a previous version of Internet Explorer ends up getting parsed and applied incorrectly.

  26. AC says:

    "Actually, I don’t get why you guys keep working on Trident, it’s outdated and broken and it’s a waste of time. "

    I think that’s precisely why they keep working on Trident. They wouldn’t if it were not outdated and broken. Waste of time is subjective.

  27. Brian Fink says:

    Cancel that last comment. I was reading the documentation wrong, and there needs to be a space between the letters IE and the number 8. 😐

  28. <p>Glad to see the work on standards work under the hood. When will we see support for SVG and MathMl without plug-ins, something far more useful to an academic like myself? These technologies let me create clean, tight, reusable code for course materials such as <a href="; title="SVG capable browsers only!">quizzes</a>. MathMl in SVG is going to be critically useful for <a href="; title="FireFox 3, Amaya 10 only">diagrams</a> in physical science. These are the "standards compliance" I am looking for!</p>

  29. Brian Fink says:

    Certain css properties unique to CSS 2.1 only get applied in IE8 Standards Mode, which could be confusing to those of us who sometimes forget the DOCTYPE tag. One such example is outline and its cousins. I was about to report that the outline property had failed when I decided to try placing a DOCTYPE tag at the beginning of my document, and the outline MAGICALLY APPEARED!

  30. Aaargh! says:

    "Your complaints are directed at the wrong team."

    My point exactly! Why are they 2 different teams ? Why maintain 2 render engines when you can only have one ? WebKit runs fine on Series60, and the average S60 device has less powerful hardware than the average Windows Mobile device.

    "I don’t think they care if it’s cross-platform or not. If it’s Windows-only that allows them to optimize it for a single platform."

    Then why does Tridents performance suck compared to the other, cross-platform, render engines ?

    "I think that’s precisely why they keep working on Trident."

    But can they ever catch up with the other browser makers ? I don’t believe they can, Microsoft is too big a company, they can’t react fast enough. Why not just kill Trident and join in with either the WebKit or Gecko team ? It means a better experience for IE users, a MUCH better experience for web developers, less work (and thus more $) for Microsoft, More developers for WebKit or Gecko so they can move ahead even faster. Everyone wins.

    MSFT is suffering from a really, *really* bad case of not-invented-here syndrome. And it’s coming back to bite them in the ass.

  31. Mike says:

    @Aaargh and others

    You must be in dream land if you think that Microsoft would kill trident and join in with webkit or Gecko. Microsoft is a business and so purely interested in making money. This is why open standards such as SVG and MathMl are not going to be part of IE8. A company with Microsoft’s resources could easily implement these and everything else the community is asking for.

    To quote an internal email from Bill Gates recent released.

    "One thing we have got to change in our strategy — allowing Office documents to be rendered very well by other peoples browsers is one of the most destructive things we could do to the company."

    "We have to stop putting any effort into this and make sure that Office documents very well depends on PROPRIETARY IE capabilities."

    "Anything else is suicide to our platform …"


  32. Aaargh! says:

    "A company with Microsoft’s resources could easily implement these and everything else the community is asking for."

    Really ? I think it’s the other way around, Microsoft being such a big company is their biggest problem and one of the reasons the can’t implement stuff like that quickly. They’ll spend months having meetings fill boxes full of minutes and documentation before even a single line of code will be written.

    As it is now, the gap between Trident and WebKit/Gecko is getting bigger and bigger. Microsoft is failing to keep the distance between Trident and Gecko/WebKit the same, let alone that they are closing in.

    That Bill Gates e-mail is 10 years old and no longer relevant. MS can’t continue like that and I’ll tell you why: Mobile devices are getting more and more important. The web and the ‘mobile web’ are converging. Just look at the success of the iPhone, but also the popularity of Windows Mobile devices and Nokia’s platform.

    Now the mobile phone market is way more diverse than the PC market. You can’t just build your site, test it on IE and Firefox and be done with it. You need to support a lot of different mobile devices.

    In order to do this, your site needs to adapt to the devices capabilities, on a fancy phone/browser you get a better looking site with more features than on a cheap phone. Technology already exists to do this. Once you have this capability, and more and more websites are going to do this, it’s relatively easy to design a site with all the cool bells and whistles that modern browsers offer, and still be able to support IE by automatically scaling the website down to a more primitive version.

    The end result for the consumer will be that when visiting their favorite sites in IE they won’t look as good as in other browsers, or they won’t have all the features available. IE’s market share will collapse.

  33. Mike says:


    I think you make some good points. However because of it having biggest market share it is very difficult for a designer to create a page or web application that does not work as well in IE.

    If a page is mainly text and images there is a not much of a problem.

    However if a mathematician want to incorporate formulas they have three choices.

    1) Use images only. (works on all browsers but very limiting)

    2) Use MathMl (exclude most popular browser IE)

    3) Use both and serve images only to IE.

    Sadly as things stand most people would go for choice 1 since choice 2 limits their audience and choice 3 is a lot more work.

    The same situation exist with using svg.

    Microsoft know this, the email may be ten years old but the culture has not changed.

    Until developer start taking the third choice we won’t see support for these standards.

  34. anonymous says:

    Hey IE team, usually IE since Windows 2000 was serviced as part of the Windows service pack. So, does Vista SP1 contain IE7 SP1? Also, how to obtain IE7 SP1 on XP? Or XP users need to download individual hotfixes. Also, are IE7 related hotfixes for Vista released as IE7 KB QFEs or as Vista KB QFEs?

  35. anonymous says:

    How about making an updated build of IE7 that includes all the hotfixes? Like a service pack? OR will XPSP3 also service IE7 if it is installed or will it not touch it?

  36. win says:

    IE is rubbish and i think it will not change fast. too slow, too ram consuming,,too microsofty..

  37. Wczasy says:

    I’m not agree, we can notice big evolving, very good job. I’m keeping fingers crossed on IE8

  38. Matt S. says:

    Don’t pay any mind to the idiots that troll the IE blog MSFT.. Long life IE! Love what your doing with IE8.

  39. Lars says:

    @Olly  .setAttribute() should set any attribute on any element.

    If i "set an attribute" in the HTML, that is an "onclick", then it registers an event handler.  The simple fact that IE is the *only* browser that doesn’t do this, when calling .setAttribute() indicates just how far behind all the other browsers it is.

    Here’s another one…

    var myPre = document.createElement(‘pre’);

    var myStr = ‘ThisnShouldnAppearnton multiplenlines’;


    Now, render the above in any non-IE browser, and it does *EXACTLY* what you would expect!

    render it in ANY broken version of IE, and you get a long horizontal string of text in your PRE-FORMATED element.

    Of course, there is a workaround, if you know this bug, but it is beyond pointless.  Enough of the hacks, just FIX IE!

    @Matt S. Those trying to get IE to follow standards are not idiots.  Those that think unconditionally that IE is the coolest thing since sliced bread – indicate their naiveness when they make any comment indicating that they think "IE is da bomb", "Best browser EVA", or in your case "Long Live IE!"

    Take 30 minutes to do a Google search for bugs in IE. If you can’t find at least 100, you aren’t trying.

  40. V. Garg says:

    A bit offtopic, but i am stuck.

    on visiting this link  using IE8, the small plus signs, which are expected to expand to show relevant content, do not work. On depressing the "emulate ie7" button they do work with ie8. Firefox also does not seem to have this issue. May I have an explanation to this behavior. thanks.

  41. @Lars

    The failure to completely and fully support setAttribute is a bug but there are perfectly valid, working and forward-compatible alternatives and workarounds to such imperfect, incomplete setAttribute implementation. Just by using DOM 2 HTML methods

    (eg: cellpadding and cellspacing: ), web authors can work efficiently and elegantly around the current limitations of setAttribute in IE (IE7 or IE8b1). IMO, there are other bugs which constraint web authors more, much more than setAttribute bug and they are being addressed (inline box model) or have been fixed in IE8b1 (eg floats and adjoining margin collapsing).

    You coded:


    but this must be a mistake. I’m sure you meant to write


    Sometimes, posters in this IE blog have a tendency to confuse bugs (incorrect implementations, spec violations) and unsupported properties/attributes/methods: those are 2 much different issues. Or they have a tendency to give more weight to unsupported properties/attributes/methods than to bug fixing.

    Regards, Gérard

  42. @Lars

    You said:

    "render it in ANY broken version of IE, and you get a long horizontal string of text in your PRE-FORMATED element."

    I tried it, tested it and it worked as expected in IE8b1.

    I’ll upload my testcase on my site if we need to go this far…

    Regards, Gérard

  43. 2- You said "getElementById finds only elements with matching id (not name)"

    That’s not entirely correct:

  44. 4- defaultChecked is still not completely supported:

    See bug #7 at my site

    5- Caption box is rendered inside table box when BC is collapse

    See bug #44 at my site

    6- rules="all" attribute specification not supported in border-collapse: separate tables

    See bug #69 at my site

    7- implicit form of label and accesskey support is very weak or inexistent:

    See bugs #47 and #70 at my site

  45. 8- You said "<OBJECT> now supports native image loading"

    Nevertheless IE8b1 still fails 5 tests at

    eg IE8b1 fails

  46. Mitch 74 says:

    I’d enjoy one thing tremendously: full support for addEventListener and removeEventListener (with corollary event capturing capabilities), along with ‘advanced’ events like DOMContentReady – that would allow me not to have to use tricks like polling page loading and ‘document.write’ing deferred Javascript.

    It would also be nice to have support for a more advanced version of Javascript: 1.2 is a bit outdated, considering most current browsers support version 1.5 at least, and along with it, actual support for Javascript’s correct MIMEtype (not text/javascript, but application/ecmascript).

    If you tell me this is in the hands of the Jscript developers, it’s not my problem: other browsers embed Javascript support in the browser, MSFT don’t: MSFT’s problem.

    On to another topic.

    I’m using SVG to generate graphs dynamically with PHP routines. It works very well with any browser out there and allows fast, easy development and testing. However, I’m forced to reject IE because IE can’t understand embedded SVG (or any SVG, period).

    So, when I develop websites, I’m actually forced to ask my users to download ‘any browser other than IE’ because IE is just too outdated – even the very latest beta version.

    However, once I’m done with IE, I barely need to test my sites: they render consistently between browsers and platforms, cutting my dev time in half (if not to a third, since I don’t waste time looking for an awkward and complicated workaround that may negatively affect the other browsers).

    What am I asking for?

    – embed an SVG plugin in your browser: there are enough of them out there to do that with barely any dev time.

    – support events correctly: you’re 10 years late on that count.

  47. 9- DOM 2 HTML, Interface HTMLSelectElement on the add method:

    void add(in HTMLElement element, in HTMLElement before)

    Not working in IE6, IE7, IE8b1 in at least 2 situations:


    Very disappointing, annoying… and not in your todo list, Mr Leithead

  48. Ferenc Veres says:

    Keep up the good work! I think the gray-out URL bar is good idea (the light one is too light for my eyes anyway, please check accessibilty colors).

    But it should be more strict on what’s important. E.g. if the site starts with "www", gray out, but on "" all this could be black.

    E.g. it does actually matter(!) whether you are on "" or ""! IMHO.

    @Vitaly Harisov: I agree! My site looks quite weird with those IMG ALT tooltips. I don’t write "title", but mouse over an image and seeing "This is a big white dog running towards a palm tree on the beach." may make IE users think I am stupid. I guess they do wonder about all my tooltips! 🙂

  49. Ferenc Veres says:

    IE8 has VERY GOOD implementation, as I ran my old tests, I see TWO issues to remain:

    ONE: Border-style: hidden should hide border.

    Make all your "table" and "td" have green 5px solid. Then make a class for them: "hidden { border-style: hidden;}". The table stands with a BLACK 1PX SOLID, which is definately a bug somewhere.

    Border should not be visible. "table: hidden, cells: none" and "table: hidden, cells: hidden", these two combinations affeced.

    TWO: inset and outset should fall back to ridge and inset, and they don’t.

    Still much better than IE7, good job, thanks!

  50. @Mitch74

    "full support for addEventListener and removeEventListener"

    Bug 333958 was requesting W3C DOM Events Listeners but was recently closed "by design". Despite 14 votes for it, I guess the IE team just had too much to fix and to implement. I know DOM 2 Events interface took quite a bit of time to implement at Mozilla and at Opera…

    And as for SVG plugin, all 3 SVG bugs/suggestions/feature requests have been closed too.

    Regards, Gérard

  51. anonymous says:

    OOXML uses VML and Silverlight uses WVG.

    Microsoft just won’t care about SVG.

  52. Steve says:

    Thanks Gerard!

    We have sites all over the net pointing to bugs in IE but it seems that Microsoft is not willing to admit to them until they are published in this blog.

    I too want SVG support, it is a key feature in the "reasons why IE is holding back the web".

    I think you mentioned that there is a workaround for all .setAttribute bugs in IE.  I’m not sure I fully accept this, as setting the name attribute in IE after an element has been added to the DOM is impossible AFAIK.  You can set it for the form submission on form fields, but it won’t update the JavaScript DOM/Namespace such that it can be accessed by name.

    I also want to point out that the IE Feedback site is rather frustrating because there is no FIXED status.  Thus anything ever entered in it as a bug can’t actually be tracked as FIXED, because MS doesn’t even have that as a status.  It makes entering a bug very loathsome because you know they aren’t going to fix it.  It merely tracks what developers want so that they can *hopefully* prioritize fixes for IE9.

  53. David says:

    yawn yawn yawn  talk talk talk

    when will Beta 2 come out ????

    some in i like to see fixs in IE8

    on WU when evere i hit link or image a little bar come down and says temporary allow scriped window  could this be fixs to where i wont have to do that in IE8

    can some one yet me no on that part thanks is some in being done about it???

  54. says:

    El blog de Internet Explorer ofrece un artículo explicando las mejoras de HTML y DOM recogidas en la primera beta de IE 8

  55. @Steve

    "it seems that Microsoft is not willing to admit to them until they are published in this blog."

    That’s not what I think. It takes *_time_* to develop an entirely new rendering engine, avoid errors of the past (hasLayout, peekaboo, guillotine, phantom, float model, margin collapsing, correct+reliable CSS parsing engine, etc), it takes testing, etc. People are demanding support for *_relatively_* new stuff (CSS 3 opacity, CSS 3 border-radius, HTML5 canvas, SVG, DOM 2 Events, DOM 3, MathML) when there is still quite a lot of bug fixing (and code optimization and module implementation) to do on HTML 4, DOM 1 (that’s right: DOM 1!), CSS 1 and CSS 2.1 and testing, code optimization, footprint reduction, creating better development tools, a real external bugs database for beta testers, improve lots of areas and modules, etc,etc.

    Also, many years ago, Microsoft said they were not closing the door to MathML but that, for speed and performance reasons, it would be better to offer a plugin or an extension for this. Understandably, not everyone needs to view a webpage with a MathML-capable browser…

    DOM 2 Events interface: it took Opera 2 years to implement and after that, there were bugs to fixed. Roughly the same is true for Mozilla.

    Just read this blog for the last 2 years and you’ll have the impression that everyone wants everything: security, speed, full standards conformance, SVG, DOM 3, CSS 3, HTML 5, latest ECMAScript, etc.. Realistically speaking, it is not possible to do everything in such short amount of time.

    People have to see the difference between a bug (incorrect implementation, spec violation) which may be considerably constraining and an unsupported property/attribute/method. And then they should be able to weight and compare for how long the support has been missing by web developers. One quick example: <option disabled> (unsupported) is not as new as <canvas> (unsupported).

    Regarding setAttribute: most of the time, a web developer can use DOM 2 HTML attribute instead of setAttribute. I gave the example of cellspacing and cellpadding: it’s web standards compliant, it’s forward-compatible, it’s efficient, it works without a itch in IE6, IE7. Is there nevertheless still work to do and bugs to fix in setAttribute? Yes. But then people should not over-exaggerate the annoyance/severity/gravity of the incomplete support for setAttribute.

    Regards, Gérard

  56. ted says:

    Ok so never really seen anything new about the status bar but i have this suggestion about those tiny icons on the status bar that shows up or permanently place their u know: Privacy report icon, manage add-ons icon, IE security setting icon, restricted&trusted site icon. can we just have one mouse click to access those icon.

  57. Jim says:


    > People are demanding support for *_relatively_* new stuff (CSS 3 opacity, CSS 3 border-radius, HTML5 canvas, SVG, DOM 2 Events, DOM 3, MathML)

    While I generally agree with the point you are making, the IE team *do* have an awful habit of being utterly unforthcoming when it comes to details unless they are announcing improvements.  It leaves people wondering if they are silent because they are ignoring the issue or silent because they are waiting until they have completed the work before announcing it.

    And I can’t agree that DOM 2 Events is "relatively new".  That specification is 8 years old, and yet they are working on HTML 5 stuff despite that specification not even being anywhere near finished yet!

  58. @Jim

    "It leaves people wondering if they are silent (…)"

    They receive orders and strict directives to stay quiet about any details: it’s part of their Non-Disclosure Agreement. They obey orders given by top level managers. They are not the ones who can make announcements like module managers.

    DOM 2 Events is 7.5 years old. I agree with you that it’s not relatively new. I was hoping that DOM 2 Events would have been fully supported in IE8b1. The other stuff though (XForms, HTML5, CSS3, DOM 3, SVG, MathML, etc) is rather new.

    Regards, Gérard

  59. Mitch 74 says:

    @Gérard: well, since every time I try to connect to the bug tracker and vote for features I get a blank page or a redirection or a server error (yay IIS!), I mention it here…

    To learn that both were rejected ‘by design’ seems to show that "don’t break the web" and "improve compatibility" really are empty statements. The very least they could do is keep the bugs open and tag them "later"!

    Eventhough it took Opera and Mozilla 2 years to implement their event models, please remember that at least part of an event model exists in IE – so, it’s not as if the IE team starts from a blank state. Moreover, the very fact that Mozilla, Opera and KHTML already provide polished and documented event models should cut down on development time tremendously.

    Simply put, a team the size of IE’s should be able to implement such a feature in a few months – and make it part of a beta so it can be tested and refined by the community.

    But, of course, since this would require upgrading Jscript, it’s not possible – considering MS’s fast development speed, where it takes 6 months to change an icon, 9 months to design a shutdown button, and 5 years to develop a bloated OS beta update, I guess it is, indeed, too much to ask.

    Keep the faith! IE 8 will reach Gecko 0.8’s level in 2008!

    Ain’t that, like, 8 years late? Ooooh, I found a trend!

  60. Justin says:

    I think this is the real issue.

    Pace of development.

    With the size of Microsoft, implementing 7.5 year old specs should not take so long.  Taking 7.5 years would be considered a very long time, BUT IT ISN’T EVEN HERE YET! So I’m led to believe you’ll need to tack on another 2 years to see this feature see the light of day in IE9?

    This is all compounded by the fact that there are two other problems with the IE team at Microsoft.

    I’m not trying to blame specific people, just underlining a bigger issue.

    1.) There is *NO* published list of *KNOWN BUGS* by Microsoft for IE (*ANY VERSION*) anywhere!

    having this would solve a lot of headaches because developers could actually see up front what won’t work before they fall into traps.

    2.) Knowledge Transfer.  I can’t count the number of times that someone on this blog, or in an IE Chat, IE newsgroup, or IE Feedback (when it is running) that a comment is made about a bug, and the response from Microsoft is either:

    a.) Never seen that before, we’ll look into it

    b.) "Closed By Design" (when refering to a legit (and often glaring) bug

    This drives developers nuts because these bugs are common knowledge, and often documented on several blogs/sites across the net.  Not having a centralized PERMANENT Public Bug Tracking System just doesn’t cut it any more.  If you have a small software project, then fine, but when 10,000+ developers are developing on your software "platform" daily, you ABSOLUTELY NEED to openly communicate with the community.

    3.) Bugs in Connect/Feedback.  The status "Closed" is only valid for "Things that are not a bug (e.g. resolved)", or "If we had an eternity to build this, it just wouldn’t get finished"

    Otherwise, bugs are "Open" until fixed.  They might get pushed to a future release, but they never close.

    I’m not saying you need to open a bugzilla account, but MS does need to do something about this problem.

    Folks aren’t entering bugs in Connect because we’ve been bit by the "cry wolf" scam before.  Commit to keeping a system open (preferably something better than Connect), and then watch the Community HELP you organize, sort, and prioritize bugs FOR YOU!  Test cases that everyone can access, pointing out the exact location/circumstances for a bug.


  61. Max says:

    Hi Justin,

    Its by no means a complete collection but i’ve started to collect bugs in IE (and al browsers) that tend to be the "most frustrating" out there at a site called "Web Bug Track"

    There is already several dozen of the more obvious bugs there, and you can always submit more.  As for the "future" I promise to link into whatever bug tracking system Microsoft uses so tracking the bugs will hopefully be easier regardless what Microsoft uses.

    The good news is that a bunch are already fixed in IE8 (beta 1).


  62. Ted says:

    Max: Without offering comment support, your bug tracker isn’t very useful.  There’s no way to discuss your "bugs" and workarounds, etc.

  63. Dave says:

    What about the styling of SELECT tag option???

    ie. Set width of SELECT tag to 100px, and set the width of its option tags to 200px?

  64. Bob says:

    What have you done to fieldsets?!?  Why have you changed the way fieldsets render?  The legend should be straddling the border, not contained within the fieldset.  Are you deliberately trying to ruin the lives of web developers who would like their sites to render the same in all browsers?  I seriously hope you fix this issue as I am becoming very tired of having to find work arounds for your clear lack of ability to develop a browser that works correctly.

  65. Carl says:

    @Ted: if you read the links on Max’s site feedback is welcome, he just doesn’t want a mish-mash of confusing (and often conflicting) comments.  If a "better" way to do something exists or you provide a workaround he will update/post it. I know because he fixed a few typos in some sample code with table innerHTML that I pointed out.

  66. Ted says:

    @Carl: I don’t need a censor to decide whether or not I get to point out his mistakes.  I’d rather have a community effort.

  67. Chris Denman says:

    Please, I beg of you! – My life would be made so much more pleasurable if there was a good way to browse using the keyboard (not holding down TAB). To that end, PLEASE implement Find As You Type search like Firefox has, I can’t live without that in IE7! I rely on the way it focuses links and I can press Enter to follow. Please, please do the same functionality!

  68. I always find comment on the time required to implement humorous. SVG dates back to 2000, the XHTML+MathML+SVG as a document type dates to 2002. I began playing with SVG in the wake of FF 1.5 in October 2006, shifted the math science college labs from IE to FF to support SVG and MathMl, and now the college math students here in Micronesia "grow up" on FF and pages that include MathMl and SVG. This year we moved the labs to Ubuntu. I suspect that for academic institutions whether or not IE "x" will support SVG or MathMl is rapidly becoming moot. Maybe someday IE will support SVG, and MathMl. The matter is increasingly irrelevant. Time is not on the side of IE. That said, a diverse brower choice ecosystem is ultimately good for the web – the days of the browser market being dominated by one player were not good for the web. So I hope that IE does implement SVG and MathMl and remain a flourishing part of the browser ecosystem.

  69. Alan Hogan says:

    Please add "impossible to style < HR > elements" to the list of known issues you don’t plan on touching.

  70. maxim says:

    Good news on the handling of <button>. It’s really great to see the direction IE8 is headed, keep up the good work!

  71. @ Travis Leithead


    "<OBJECT> now supports native image loading"

    That can not be true or there is something wrong with my understanding…  and I’ve read the white papers. IE 8 beta 1 *_fails_*:

    and many others regarding image loading


    "<P> element now closes when <TABLE> is encountered (ACID 2 compliance)."

    "To be compliant with HTML 4.01, the P tag must close before any non-inline element."

    That is still not entirely true for IE 8 beta 1 for *_all_* non-inline elements (unclosed p immediately preceding a form element):

    This bug is not in your to-fix-for-IE8 list.

    3- The DOM 1 HTML and DOM 2 HTML add method for select needs work, fixing:

    DOM 1 HTML and DOM 2 HTML add method for select is not in your to-fix-for-IE8 list

    Regards, Gérard

  72. Working this evening I came across my first need to use addEventListener….



    If a bug exists for addEventListener I’d appreciate it if one of our JavaScript gurus could please point me in the direction so I can add my vote.

    Looking forward to Beta 2!

  73. Mitch 74 says:

    @JAB III: the bug for addEventListener, as Gérard said, was resolved WONTFIX ‘by design’ (to use Bugzilla’s nomenclature, since I have no idea what the MSDN bug tracker uses – I’ve never seen it working!).

    In short: addEventListener isn’t supported by IE – any version. You can obtain a similar effect for this sequence with elements[i].attachEvent(‘onclick’,changecolor).

    Problem 1: the event listener works on a window object level; if changecolor() uses ‘this’ to refer to the object, in IE ‘this’ will refer to the window! So, under IE, you need to detect the event’s target and explicitly pass the node to the function.

    Problem 2: since IE doesn’t support event bubbling, your event listeners need to be put on elements without children – or the event won’t fire if, say, you click on the bold text inside your button…

    Problem 3: since IE can’t control event capturing on an object level (it does it at the window object level), you can’t emulate bubbling by disabling then re-enabling event capturing with timers.

    In short: under IE, use legacy Netscape 4 event attributes, or get ready for loooong sleepless debugging nights.

    Yes, events under IE are a joy to work with; it doesn’t need addEventListener, oh no sir!

  74. Resimler says:

    thank you.Long life IE! Love what your doing with IE8.

  75. Daniel says:

    @Gérard Talbot: ————————————————

    Internet Explorer 8 will no include a whole new rendering engine. It’s still the old Trident engine.

    Every once in a while you can clearly see the Trident.

    For example hasLayout is gone, but I’ve seen testcases (sadly, I forgot the address) that showed how the old hasLayout triggers can still be used to achieve certain behaviours (for example relative positioning that makes the whole area :hover-able).


  76. Daniel says:

    @Gérard Talbot: ————————————————

    Oh, here’s a good example. Test it in IE8b1!


  77. minikperi says:

    I want securely IE than other browsers.

  78. Paulo Santos says:

    Ping back from PJ on Development.

  79. eM says:


    By that logic, shouldn’t Mozilla abandon Gecko for WebKit? Gecko (Firefox) is clearly the inferior rendering engine to both WebKit (Safari) and Presto (Opera). In fact, Mozilla’s gone so far as to say that passing Acid3 is a non-goal (both WebKit and Presto hit 100% compliance weeks ago).


    IE7 *is* more secure than most other browsers (Opera, being the exception, is more secure; Firefox is substantially *less* secure).

  80. I have another great idea: could you folks please make the text in JavaScript alerts selectable? It’s selectable in Firefox and Opera though not Safari. At this very moment while I’m working on my site’s next designer & development milestone and in between IE8 B1 & B2 I’m working on finalizing CSS on my site so I do not have IE8 running to see if the text has been made selectable so if it already is then thanks! 🙂

  81. If you did not know Microsoft is currently working on Internet Explorer 8 (IE8), you may ask why a new

Skip to main content