Gotchas in Internet Explorer 8

Internet Explorer 8 (IE8) is at Release Candidate 1, which means it will be released very shortly. IE8 is a brand-new browser and will represent a considerable shift from IE7/IE6; it will follow standards more closely and will offer much improved CSS 2.1 support. However, because of some of these changes, it is also widely understood that IE8 might break websites that have relied on IE-specific hacks targeted at previous versions of Internet Explorer.

To their credit, the IE development team has been very candid about the changes and have posted a number of blogs and documents aimed at helping web developers prepare for IE8. I was looking over one such page and thought I’d point out what I consider to be some of the biggest ‘gotchas’ so far.

Setting Unsupported CSS Values

Trying to detect support for a specific CSS value through a JavaScript try/catch statement will no longer generate an exception, which means you can’t rely on JavaScript to detect support for specific CSS values anymore.

Assigning CSS values that were unsupported in IE7 but are supported in IE8 Standards Mode will not generate exceptions in IE8 Compatibility View. Some sites use these exceptions to determine if a particular value for a CSS property is supported or not.


try {
   elm.style.display = "table-cell";
} catch(e) {
   // This executes in IE7,
   // but not IE8, regardless of mode
}

Malformed HTML

IE8 will not be as forgiving of malformed HTML markup. This is a great new ‘feature’ in terms of ensuring people (and software) are less sloppy with their markup, but this will certainly cause many, many problems for hundreds of thousands of old, poorly written websites.

Parser error correction for malformed HTML has changed in IE8 Standards Mode. Pages depending on the way IE7 performs error correction may encounter issues as a result.


<ul>
    <li>1.1
        <ul>
            <li>1.1.1</li>
    </li> <!-- Closes 1.1 in IE8, but not IE7 -->
            <li>1.1.2</li>
        </ul>
    </li>
</ul> 

Working with an Element’s Class

Like the malformed HTML ‘feature’, this is another great improvement in IE that will also cause many, many headaches. You see, for years IE wouldn’t let developers use the standard setAttribute("class") method for specifying a class name via JavaScript. Instead, IE required developers to use the proprietary setAttribute("className"). This means that it became commonplace for scripts to check for IE then use class for non-IE browsers and className for IE. Now, you’ll still need to make that check for older versions of IE but find a way to use class for IE8. <sarcasm>This will be fun.</sarcasm>

Don’t get me wrong — I’m excited that IE will finally behave like other browsers in this regard — but it also means that so long as IE6 and IE7 are still around, we’ll have to jump through more hoops to handle class names.

In IE7, “className” had to be used as the attribute name to set and retrieve the class of an element. This has been fixed for standards-compliance in IE8 Standards Mode. Using the old approach will create an attribute named “className” that has no affect on the actual class assigned to an element.


return elm.getAttribute("className");

SOLUTION: Use the standardized name, “class”, instead of “className”.


return elm.getAttribute("class");

CSS Expressions

One of the common hacks for IE’s shortcoming with CSS support has been to use IE’s proprietary CSS expressions, which are basically JavaScript statements embedded in place of a CSS value. While this practice has been frowned upon by most in-the-know web developers, it still wound up being heavily utilized as an ‘easy fix’ type of hack.

IE8 will no longer support CSS expressions. This will make it behave more like other browsers, but will cause problems for those who have relied on CSS expression hacks. Fortunately, it should be relatively easy to move your CSS expressions into your page’s JavaScript as suggested by Microsoft.

Support for CSS Expressions has been removed in IE8 Standards Mode.


/* CSS */
#main {
    background-color: expression(
        (new Date()).getHours()%2 ? "#000" : "#fff"
    );
}

SOLUTION: Refactor to utilize either improved CSS support or DHTML logic.


/* Script */
var elm = document.getElementById("main");
if((new Date()).getHours()%2) {
    elm.style.backgroundColor = "#000";
} else {
    elm.style.backgroundColor = "#fff";
} 

On the whole, I’m excited about the changes IE8 will bring, although it will undoubtedly require site revisions for anyone who uses JavaScript extensively in their projects.

You can read the original Microsoft blog post here.

I hate to say it…

But I found another Microsoft product helpful today.

It pains me to say it, but it’s true.

I have created an XML template for an online course delivery system I’m building at my workplace. The course data for each course needs to be placed into a copy of this XML template. The problem is that I don’t want to work directly in XML all day, and my coworkers can’t be expected to write course content directly in XML format. I needed to devise an easy-to-use method for inputting data to an XML document (filling in the blanks).

My initial research into the subject found some ‘export-to-XML’ methods that use Excel and/or Word, but they are prone to formatting errors and require extensive workarounds such as oodles of conditional formatting. Didn’t sound very fun. Not to mention the custom XML schema I’d have to write to enable the Excel/Word file to be properly transformed to my custom XML. Other methods involved databases and content management systems, which I wanted to avoid for simplicity’s sake.

Enter: InfoPath. A “how’d I get that?” program that came with our Office 2003 update a few months ago. I had never heard of it until I saw it while randomly browsing my computer’s Program Files shortcuts.

Turns out it’s a program for designing forms that are connected to a data source such as an Access database or… you guessed it… an XML document. And what I truly found surprising is that you don’t need an XML schema, just a sample XML document that follows the format you want your future XML docs to be in. A copycat, so-to-speak. InfoPath will automatically infer the schema from your sample XML! Note: you should probably go in and check the schema details, such as using a “date” data type rather than “integer”.

InfoPath was very easy to use. I created a new blank form, then selected my sample XML file as the data source; InfoPath made the XML tags available as drag-and-drop items, kind of like Flash components. I quickly arranged the items how I wanted them (including using “repeating regions”), and voila!, I had a fully functional form in one afternoon. The data entered into the form is exported to a fresh XML file — based on and validated against my custom XML — whenever I hit “save.”

Of course, that’s a very simplified explanation of how InfoPath works and what it does… I’m still a newbie with the program. However, I can say it greatly simplified the work I needed to do (no crazy workarounds using multiple programs), gave me a form I can share with my coworkers (although you need InfoPath to use the form), and produced valid XML that I can import into other programs as needed, all in one afternoon.

I should note there are other programs that perform similar functions, including Adobe Designer (companion to Acrobat Professional). I will have to investigate the alternatives — I hate being beholden to Microsoft — but so far InfoPath is leading the pack.

http://office.microsoft.com/en-us/FX010857921033.aspx [link no longer available]

Daily newness: An online XML-to-XSD Converter

OK, most of you probably don’t know the difference between an XML file and an XSD (“XML Schema”) file. For a brief intro check out W3Schools’ XML Schema tutorial. A brief quote: “The purpose of an XML Schema is to define the legal building blocks of an XML document, just like a DTD.”

This week I needed to create an XML Schema doc for work. The XSD file would be used to validate XML files I’ll be making for my online courses. Well, being a newbie to XSD files (though not XML), I was making decent but very slow progress when a thought occurred to me: it should be possible to reverse-engineer an XML file to create an XSD file. And, considering how prevalent XML is these days, someone probably posted an online converter for it! Google to the rescue!

I found a number of tools (mostly software downloads such as XMLSpy), but the easiest one I’ve tried so far is by — gulp — the Evil Empire itself: Microsoft.

http://apps.gotdotnet.com/xmltools/xsdinference/ [link no longer available]

All I can say is whether you love ’em or hate ’em, their tool works great and is completely free. On my first try it pointed out some invalid XML I had written. After correcting my mistake, BAM!, I had a complete XSD file. It wasn’t perfect and needed some tweaking (optional versus required tags, string v. integer, etc.), but it eliminated most of the heavy lifting for me and I’ll be finished a heck of a lot sooner than I would have been without it.

Umm… thanks, Microsoft! (For once…)