DEL is your friend

Those cases happen rarely but when they do, I always resort to a tested and tried technique: isolate the problem by removing or commenting all unneeded markup. Isolating the problem may take some time but when you have a web page with a minimum of HTML while keeping the styling bug intact, you get in most cases the bug fixed in no time.

Why does isolating code work so well? Well, most of the time you can find styling bugs by experience, but when you’re stuck, every bit of styling on a tag becomes suspicious and that’s just too much to test. The bug becomes a needle in a hay stack.

Removing the easy way

The best way to remove blocks in a page is by just adding a display: none to its styling via a developer tool like Firefox’s Firebug, Opera’s Dragonfly, Webkits developer tools or IE’s Web Developer Toolbar. Just cut away big blocks and each time you remove something, you test if the bug still persists. You continue until you find the block that is triggering the bug. Most of the time you’ll have to continue the same technique of removing bits of code within that block until you can isolate the problem.

Hiding a block by adding a 'display: none'

Removing a block of HTML completely

Removing the source code

Sometimes it’s better to have direct access to the source HTML than doing temporary changes in the developer tool. But if the HTML is (partly) created server side it’s hard to easily remove stuff. In those cases when I’m really desperate, I request the HTML source from the browser and save it in the directory the original web page resides. Then I can make dramatic changes to the code and test in multiple browsers without affecting the site itself.

Is this an efficient way of debugging? Definitely not, but sometimes you just need to do it. It happens to me once or twice a year or so and by debugging that way I always managed to find the root of the problem.

Related posts:

1. CSS debugging
2. Tips for using and debugging of Less CSS code

For example: progressive enhancement in practice means that if you want to implement rounded corners, you’d use the border-radius style instead of a stack of images of rounded corners. But what if rounded corners are one of the corner stones of the corporate design of the client? Loads of users on IE7 and IE8 would miss that recognizable feature of that corporate design.

The design choice of rounded corners are sometimes a matter of taste, but most clients care for their corporate identity. So if you are ready to slaughter someones design in IE7/IE8 with progressive enhancement as your alibi, make sure that the features that will be missed in those browsers are not an important part of their corporate identity.

Related posts:

1. Do you create your design in Photoshop or Notepad?

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.

What are media queries

To explain what media queries are, it’s best to start with the standard media types. Media types were introduced as part of the CSS2 specification way back in 1998 and is supported by all major browsers. The most common are “screen” (desktop PC’s), “handheld” (mobile devices), and “print”. Here’s an example of how to link a CSS file to a media type:

This looks pretty straightforward and it is. But most mobile browsers don’t consider themselves “handheld” when choosing a CSS file. Devices like iPhone, Android and Nokia behave like a desktop computer and select the CSS that’s reserved for the “screen”-devices.

This was in some way a logical step, since most websites don’t have a CSS file for handheld devices. The drawback is also very clear: You cannot cram a web page optimized for desktop monitors in a 2′ handheld monitor without paying a price. Usability suffers. Users are given crutches like the ability to zoom in to a specific part of the page, but that’s like watching TV through a keyhole.

To address this problem the W3C came with media queries. Now you can check properties like screen size and resolution. So now you get something like this:

Now we have all our ducks back in a row. If the browser width is larger than 480 pixels, it will select “screen.css”. If the width is smaller or equal to 480 pixels, it will go for “handheld.css”. We keep our CSS link with media="handheld" as a fallback for handheld devices that don’t do media queries, most notably IE Mobile and Blackberry’s browser. Checkout PPK’s compatibility table to see which browser does not support Media Queries yet.

Filling the gaps

But this still is not enough to have your site render well in all browsers. IE and many older browsers do not handle the new media queries.

Some sort of solution was proposed on ALA, but that technique requires an extra CSS file called antiscreen.css that cancels some of all styles that were created in the screen.css. Most of the websites I make just have too much CSS styling to make that technique usable.

JavaScript can also detect the screen width, so I decided to use it to help browsers in choosing the right CSS. The script I created also checks the screen width after a window resize, just like Media Queries. Just open the demo and you will see that the page will switch to the mobile stylesheet if the window gets too narrow. Even in browsers that don’t support Media Queries (yes, I’m looking at you, IE!).

How it works

In the demo the script expects that if Media Queries are supported by the browser, a div with the class cssLoadCheck should be 100 pixels in width. To check that it this is true it will insert a div with that class into the DOM, check its width and then removes it from the DOM again. If the width of that test div isn’t 100 pixels we know that Media Queries are not supported and that JavaScript has to supply a CSS file depending on its width.

Each time the pages refreshes it removes the dynamically added link-tags in the head and adds new ones.

Possible improvements

This is just a simple script and there is lots of room for improvement. I could also built a script that figures out itself what CSS to load by looking at the media query statements in the markup. The current state of the script is good enough for my needs, so I’ll keep it like this for now.

Related posts:

1. Codeview update
2. Redirect to a mobile website
3. Codeview, a new template for JSDoc Toolkit

“There are differences between class and id. Class attributes should be used when you have more than one item on the page with the same class value. Conversely, id values have to be unique to a page.

When I first learned this, I figured I’d just always use class attributes so I wouldn’t have to worry about whether I was duping an id value. However, selecting elements by id is much faster than selecting them by class, so you can hurt your performance by overusing class selectors.”

Huh? I never use ID’s in CSS selectors, but I never experienced slow rendering either. I wanted to test if it’s stupid not to use ID’s.

First I wanted to see if it was even able to create a CSS that was hard to parse. Google has a nice article about writing efficient CSS selectors, so that seemed like a good start before setting up a test. In short there are 2 things that make a fast CSS selector:

• Make rules as specific as possible
  This means that div.content is faster than *.
  You have to be especially specific with the rightmost selector, since the browser reads CSS selector from right to left.
• Avoid (large) descendant rules
  An example of a descendant rule is div.content div.column1 div.columnHeader h2. Descendant rules are less efficient than rules with a single selector, like h2.

Test 1: setting up extremely inefficient CSS

The most inefficient selector by far is *. Combined with large descendant rules you get extremely inefficient selectors:

* * * * * * * * * {
	background: #ff1;
}
* * * * {
	background: #ff2;
}
* * * * * * * {
	background: #ff3;
}

I created a CSS file of about 20KB in size with 3600 asterisks characters (*). I combined it with a very large HTML file (1MB) with 9000 opening HTML brackets (<). Because I only wanted to test the CSS rendering, I added the following JavaScript to be able to load the CSS file on my local computer after the page was loaded.

	Load CSS
	

Results Test 1

All tests were done on my computer (Vista with Intel Duo Core @ 2.4GHz) except for IE7 and IE6. IE7 was tested on a Vista machine with Intel Core Duo SPU @ 2.67Ghz. IE6 was tested on my machine with Virtual PC and on a PC with Windows XP SP3 and a Pentium 3 CPU 3GHz.

The results show that browsers freeze for at least 2 seconds in order to render the CSS. So it is possible to screw up your rendering, but you really have to make an effort for it with large HTML files and unrealistic CSS selectors.

Test 2: setting up a more realistic scenario

In this test I created a more realistic scenario. I took an existing CSS file and altered it until it was 113KB in size and contained about 1050 selectors. I changed the CSS rules until the bulk of the code looked like this:

.Homepage .containerText {
	position: relative;
	margin: 15px auto 0px auto;
	width: 960px;
	background:#ffffff;
}
.Homepage .containerText .containerLeft {
	float:left;
	width:450px;
	padding:10px 20px 45px 10px;
}
.Homepage .containerText .containerLeft p {
	margin:0px 0px 5px 0px;
	color:#414a49;
	line-height:1.286em;
}

So most of the code in the CSS file consisted of descendant selectors with classes and hardly any tag names. The corresponding HTML page was also created from existing code and copy-pasted until the file was 107KB in size with almost 600 opening HTML brackets (<). Now we have a relatively large HTML and CSS, but not unrealistic. Once again I tested it in different browsers:

Results Test 2

All modern browsers responded so fast that I couldn’t really notice it needed rendering time. This means that the CSS file does not need any optimization by utilizing ID’s. The only browser that could profit from more efficient CSS selectors is IE 6. But since I don’t have to support IE 6 anymore, it’s not worth my time.

Conclusion

Writing fast CSS certainly will help some browsers on slow PC’s. But that is a minority of the users. So unless you have special requirements for your website, you’ll be better off focusing on writing logical, maintainable code than trying to get the browser to render a few milliseconds faster. There are some considerations though:

Being more specific

A few years ago I switched from writing .foo to writing a.foo. Adding the tag name in the selector gives me a better idea what I’m styling. Now I know that this coding style is also faster in rendering.

Descendant selectors

Descendent selectors (using more than one element in a CSS rule) are inefficient in rendering, but I won’t give that up. I like to be specific about what element I want to select in CSS. I rather write div.column1 div.article span.date than span.date. The latter is more efficient, but that only works with very small websites because only then you’d still have an overview of the all classes that are in the HTML code.

When I write JavaScript code I try not to ‘pollute’ the global namespace. I try to do the same with CSS by using descendent selectors.

If you need faster rendering, you could alter descendant selectors by making one class that incorporates the whole path. So you’ll get span.column1_article_date instead of div.column1 div.article span.date. Although it would render faster, it also has some drawbacks. Renaming a class afterwards is tedious work, the class names can become very long and the classes can be used outside it’s intended containers, so a class called div.column1_article_date could be used anywhere in the DOM and not just inside div with the class column1.

ID’s and JavaScript

I do use ID’s by the way, Not in CSS though, but for JavaScript for these reasons:

• Specific elements can be easily accessed in plain JavaScript with getElementById.
• If an element has an ID, I can be pretty surre that there is a bit of JavaScript attached to it.
• Using ID’s in your jQuery selectors makes the selectors less dependent on the current HTML structure. It’s easy to break existing jQuery selectors by removing a class in the DOM.

Related posts:

1. Too advanced CSS selectors
2. Hack: how to enable :first-child in IE6

Yeah, Netscape 4. Now that was a browser that just did not want to die. Netscape wasn’t updated after 1998 but in 2001 still about 5% of the internet users used Netscape. I got curious how the web would look like in a browser that is more than a decade old. So I downloaded Netscape 4.7 and loaded some major websites to see how they would look.

The level of accessibility of websites varies enormously. Let’s start with one of the worse:

Amazon.com

Welcome to our new and improved web shop

How the Amazon website should look like

As you can see: Netscape renders the page but context is virtually lost. And it clearly can’t handle the sprite image in the top left corner.

Twitter

A Twitter page in Netscape

How this Twitter-account should look like

The lack of solid white background color in combination with a rich-contrast background image that does get loaded is a serious problem. Not to mention all the hidden information that becomes visible. This website too is not very usable anymore.

Yahoo

Yahoo just blocks you

Yahoo has another approach: It just says that you’re browser is ancient and offers download links to newer browsers.

Google

...while Google just does it's thing

Google doesn’t complain and shows a page that looks remarkably well in Netscape 4. The links in the search results will still send you to websites that look like jigsaw puzzles, though

So you can’t browse with an ancient browser. So what?

Ok, this is indeed not a drama. But think of it this way: the web is a web of content. Content that becomes increasingly inaccessible if you don’t rebuild its content container, the website, every few years. Most organizations do that to be up to par with the latest browsers and designs but some just have to.

Help browsers with a handicap

Keeping content accessible is not just a hobby. It’s a major issue for websites of (semi)government organizations for example. They have to make sure content is open to anyone. Although they focus on handicapped internet users rather than handicapped browsers, one goal remains the same: a user should be able to use a website without the need of CSS, JavaScript or any other ‘fancy’ technique. A :hover is no use to a blind user, neither will color and JavaScript animation. That’s why such a person uses a different browser without such capabilities. And that’s why we have guidelines like WCAG.

It’s not surprising that many websites that follow WCAG guidelines or something comparable  do reasonably well in Netscape 4. I’ll repeat it again: that’s a browser from 1998.

www.section508.gov

Unique: this website looks almost identical in Firefox and Netscape

www.section508.gov in Firefox

The web design of www.section508.gov just don’t look like it stems from the 1990s, it also uses ancient techniques from that era like tables for layout, image spacers and sparse use of CSS. All big no-no’s nowadays, but the website rendering is great.

Dutch web guidelines

In black and white, but ordered and readable.

The same website in Firefox

The difference in rendering between Netscape and Firefox is striking. Netscape is unable to read the CSS, but that’s a good thing here. Accessibility dictates that an HTML document should be structured. So when there’s no CSS to style the document, the document structure will remain.

But why does Netscape not load the CSS? It appears that the media attribute link markup is key here:

Netscape won't load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" media="screen, tty" />

Netscape *will* load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" />

Dutch semi-governmental website (www.groenendestad.nl)

The website in Netscape

In Firefox

The last site is a semi-governmental website developed at the company I work, Estate Internet. It’s a relative new site (2 years old) but still usable in both old an new browsers.

Hurdles

So it is possible to make websites that are still usable in ancient browsers. The main obstacle is that old browsers try to render stuff like CSS and JavaScript but choke on it halfway. In case of CSS it’s possible to block Netscape by adding the media attribute, but that’s still a hack. Old browsers should be protected from itself. One option is to just disable everything at the client side that could harm the rendering.

It would be nice if you could send unsupported browsers just the HTML, while others also receive CSS and JavaScript. But browser detection can be error prone. The only stable solution I know that is easy to implement is IE version detection through conditional comments. Consider this piece of code that only gives all non-IE browsers and all IE7+ browser the site’s stylesheet.

<![if !IE]>
    <link href="css/main.css" type="text/css" />
<![endif]>
<![if gte IE 7]>
    <link href="css/main.css" type="text/css" />
<![endif]>

Conditional Comments will help us giving a soon-to-be ancient browser like IE6 the treatment it deserves .

Now it’s time to close Netscape again and start waiting for the new Firefox that supports basic CSS animation.

No related posts.