Check your sites in IE9. Even if you use the X-UA meta tag

Wouter Bos — Sun, 13 Mar 2011 20:19:05 +0000

The Microsoft’s X-UA meta tag is simple. Just by adding to the HEAD you can make IE8 and IE9 handle a web page like it’s IE7. That way I can support 3 browser versions but having to test only one. It saves time that otherwise would be spent on testing.

Though it may seem like a good idea, the X-UA tag was initially received with mixed reactions. Some worried for example that web developers will become lazy and would only support IE7 even if Microsoft would roll out IE15. John Resig (creator of jQuery) even would go as far as calling the X-UA tag, “completely useless” and “harmful”. He thinks that the X-UA tag will just create more confusion because there will always be differences between a native IE7 and an emulated IE7.

I decided to use the meta-tag anyway. If it really didn’t work at all I could always remove the meta tag. On top of it: most websites I work on are not that complex and simplifying test procedures is a big plus.

My experience with the X-UA

Until now I had some good experiences with the X-UA tag, but I must say I have encountered 2 differences in rendering between a native IE7 and an emulated one. That’s not much if you consider that I use it ever since the meta tag was available, but it is something we have to look out for.

One of those 2 bugs happened just a while ago. We noticed that some website did not render well in IE9 with IE7 emulation. The text that was styled with custom web fonts (loaded with @font-face) was chopped off at the top and bottom. There was no problem in a native IE7 browser. The bug below shows that although IE7 emulation works pretty well, it still may have some glitches.

The line above is a screenshot from a native IE7. The line below is from an IE9 in IE7 mode. Both run on Vista.

So it may be worth while to check some old websites you created when you installed IE9, even when you implemented the X-UA tag.

No related posts.

CSS debugging

Wouter Bos — Thu, 22 Oct 2009 20:21:16 +0000

Trace the styles

What a relief when the CSS debuggers emerged. Before Firebug or IE’s developer toolbar we had to just guess what the problem was. Now we can see exactly which selector is overruling the other. If you’re still developing without one of those tools you should install one right away. And if you have Firefox you really need to take a look at what Firefox plugins are available for developers.

Firebug in action.

So what do you do if one CSS selector overrules yours? Well, the easiest solution is to just make your style more important. The easiest way to do that is to do something like this:

.myClass {
    width: 100% !important;
}

That’s really simple, right? But as always there is a negative side to it. The !important keyword is overruling anything else. That sounds handy but it also makes your CSS harder to control. If you start to use !important at the root of your HTML-tree (like ), you’ll most likely have to use !important all the way down to the leaves.

I prefer to structure my CSS in such a way that my CSS-file starts with global selectors like p and h1. After that I get more and more specific. In pratice this means that I style the HTML structure from the root to the leaves.

A more practical way to make sure your styles are used above anything else is the use of id’s. Although I try to reserve id’s for Javascript many developers give common boxes like headers and footers an id to use in their CSS like this:

.logo {
    width: 50px;
}

#header .logo {
    width: 100px;
    padding: 0;
}

I think that id’s are not needed in your CSS, but it’s easy and safe to use.

Be explicit

Besides structuring the CSS I like to be specific about where I want to use my styles. If I think I’m only going to use some in the footer I won’t write

.leftText {
    color: #ccc;
}

but

.footer .leftText {
    color: #ccc;
}

By specifying the path in the HTML I make sure that that style is only used in the footer. And if I want I can also use that class name to style something in the header as long as I specify the path. So that way I don’t have to worry much about keeping the class names unique as long as the paths are. This enables me to use generic class names like “.text”, “.alert” or “.column” multiple times.

I use this technique of specifying paths rather to prevent debugging than as a debugging tool. But if you have two conflicting styles, specifying the paths could be the solution to your problem.

Validate your CSS

If your style just doesn’t pop up and there is no other overruling style you propably have another problem on your hand. If you care about validation you could validate your CSS. When running a validation check, you might find a type or a missing curly bracket, but I must say: I don’t get such errors on a weekly basis.

On top of that, creating valid CSS and HTML doesn’t make much sense if your team members are not validation-aware. You may end up spending too much of your time fixing invalid code.

Validate your HTML

Sometimes your website looks broken because your HTML is broken. It’s easy to leave a tag unclosed without noticing it. Another way to break the HTML is to add a class attribute to a tag that already has a class attribute. In that case the browser doesn’t pick up the second attribute. Adding a second attribute is easily done when you’re working with somebody else’s code or if you have elements with lots of attributes.

Disable your Javascript

I very rarely have to blame Javascript, but sometimes Javascript is doing more than you know or want, like adding styles to the stylesheet or on an element itself. The latter case is easily recognized if you check an element with Firebug or the devtoolbar. Some libraries like some lightboxes jam elements full with attributes.

Javascript by the way is a major reason to use a debugging tool. That’s because you cannot see what Javascript does by requesting the source code from the browser. The source code that a browser supplies to you is the raw html that is delivered by the web server, not the HTML that is altered by Javascript.

The Bright Lines » Debugging