Life @ High Road Communications

These are exciting times – and that term is used very loosely – as we near the end of IE6 and say hello to IE7  being the browser of choice for most users. With IE6 goes the near non-support of CSS selectors and we welcome a browser that support them – or does it?

There are many nay-sayers out there who complain of the lack of support of CSS selectors in IE7. From the surface, this looks to be a valid complaint as it scores quite badly (57%) as compared to other browsers, Firefox and Chrome, etc. that score much higher, and in some cases are scoring 100% on the same test.

So do we throw our hands in the error and complain again about Microsoft’s ignorance to Web standards? Yes, of course, but maybe things are not as bad as they seem?

Lets put our Microsoft glasses on and take a closer look. Once the glasses are one, you’ll realize that the browser market has just shrunk to one – funny, because you swear you’ve heard of others (FireTalk? SadFerrari?). Oh well, must be your imagination… ;)

The first thing to do is see how things have improved over the old version of IE (v6). Running the same test on IE6 gives us a  failing score of 48%. Hm-mm. Not exactly the sort of improvement I was looking for, but hey, at least we’ve got a passing grade now, [in IE7] eh?

Excuse me a moment as I remove my glasses.

GIVE ME A BREAK! FIX YOUR STUPID BROWSER YOU BUNCH OF MORONS!

Where were we? Ah yes, looking at the ‘good’ test results of IE7. I want to take a closer look at the areas where IE did not score perfectly in. For each section I will list a brief description of where it failed and then provide my comments. All test data, description and any other information is copyright of CS3.info.

E[attribute] selector (2 out of 7 failed)

• The CSS selector should match the HTML fragment because the align attribute is present and is empty.
• The CSS selector should match the HTML fragment because the align attribute is present.

Where this is failing is when you have an element that has either an empty attribute (i.e. align=”") or an attribute with no value (i.e. align). In both cases I consider these minor errors as attributes should always have some sort of value. In the case of the second test, this would be invalid XHTML anyways.

E[attribute ~= value] selector (1 out of 17 failed)

• The CSS selector should match the HTML fragment because the case of the rel attribute value should not matter in a HTML document.

The workaround for this situation is to ensure that you ensure you are using the correct character case in both the HTML and CSS, which I believe is a proper procedure to follow. 

E[attribute |= value] selector (1 out of 19 failed)

 

• The CSS selector should match the HTML fragment because the value of the lang attribute should be case insensitive in a HTML document.

Another character casing issue – again, like the last test your proper procedure should be to ensure that you using the same character casing throughout your Web documents.

:first-child selector (1 out of 7 failed)

• The CSS selector should match the inner div element, because it is the first child of the outer div element Comments are not elements, so they should not be considered when determining the first child. 

This is the first valid error that I’ve seen so far. IE considers HTML comments and plain text to be an “element”, so if any of these appear before an actual HTML element, this selector rule will fail. On a static site, or even a dynamic site that allows you full control of your HTML template, this should be a fairly easy one to avoid. However, it’s so easy to see this one causing problems – especially with multiple people working on the templates – that it should be avoided.

 

This study will be continued in the days to come. There are a lot of tests to go over, so stay tuned!