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.

Acknowledgements

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.

Regards,

Travis Leithead
Program Manager
IE8 Object Model