The Bright Lines » CSS

CSS performance, who cares?

Wouter Bos — Wed, 28 Jul 2010 05:11:40 +0000

Lately I read the following text in Building iPhone Apps with HTML, CSS, and JavaScript (O’Reilly) on using ID’s in CSS:

“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

Browser	Render time (sec)
Firefox 3.6	2
IE 8	4
IE 7	6
IE 6	11
Chrome 6	4

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

Browser	Render time (sec)
Firefox 3.6	0
IE 8	0
IE 7	0.5
IE 6	1.5
Chrome 6	0

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.

No related posts.

Codeview, a new template for JSDoc Toolkit

Wouter Bos — Thu, 06 May 2010 20:18:29 +0000

Download Codeview

The template is based on the basic template of JSDoc Toolkit. The HTML structure is basically the same, but with a complete fresh CSS in a separate file. Nothing else is added to the template (yet), so it’s a fast loading website.

There are even no pictures added to the template, although it may not look that way because of the CSS3 styles that generate gradients, shadows and rounded corners. These effects are not visible in IE, except for rounded corners in IE9. So in case of IE, you’ll just see a simpler version of the website.

Here are some screenshots:

Class view

Class overview

File overview

Taking back the control

Wouter Bos — Mon, 15 Mar 2010 20:04:41 +0000

The Bright Lines, as seen through 'readability'

Lately I came across Readability. It’s a bookmarklet (works only in FF, Safari and Chrome) that alters any website into a more readable one. It does so by presenting it in a book form. At a first glance I thought it as a nice tool, but I wasn’t sure I was going to use it. Then I thought that it was a real good example that you as a user have more to say than you think.

We always accept the usability of the websites for what it is. If it’’s good, it’s good. If it’s bad it’s bad. But the frontend of the website is built on your computer, in your browser. You have a certain level of control over the HTML, CSS and Javascript.

The most common way to make a website better is by using ad blockers. Yes, some people do live of advertising, but I don’t think that means you should be obliged to see them if you don’t want to. Especially when they distract. The best thing about ad blockers is that it doesn’t require any knowledge of web development at all.

Another example is CoolIris that convert image pages of popular websites like Google Images or Flickr into a 3D wall of images.

A more techie Firefox plugin that I use is Stylish. I use it to add my own CSS to websites I regularly visit. Most of the time I use it to remove section that I regard useless with a simple display: none. A more powerful variation of Stylish is the plugin Greasemonkey. With Greasemonkey you can alter the websites with Javascript. And just like Stylish, you can publish your customization of the website through the plugin.

So that’s a reminder for me to see that websites are not cast in stone. Popular websites will on the client side be hacked by a small minority of users to cater their own needs. And if a site is really in need of improvement, plugins that help non-technical users would spread like wildfire.

Popups dodging popup blockers

Hack: how to enable :first-child in IE6

Wouter Bos — Sun, 31 Jan 2010 00:43:14 +0000

UPDATE: The pure Javascript routine is updated. It is now as fast as jQuery.

One of the things I most dearly miss in IE6 is the lack of support for the CSS selector :first-child. Some shortcomings in browsers can be patched with Javascript. And :first-child is one of them for sure. If you use a Javascript library like jQuery or Prototype it’s just one line of Javascript:

If you don’t like Javascript libraries you can use this pure js-code:

var tags = document.getElementsByTagName("*"); var nTags = tags.length;
for (var i=0;i
Now every first child has the class firstChild that can be used in CSS selectors. You'll get something like this:
ul li:first-child,
ul li.firstChild {
    font-weight: bold;
}

The speed
Throwing around classes through the whole HTML tree is not without a price. Certainly not if you keep in mind that Javascript in IE6 is much slower than in Firefox or Safari. So I tested what would happen if the Javascript would run in the homepage of amazon.com, a page with almost a 1000 tags. Here are the results:

Adding firstChild with jQuery:

Amazon.com homepage (1000 tags): +- 215milliseconds
Five times the Amazon.com homepage (5000 tags): +- 742 milliseconds


Adding firstChild with plain Javascript:

Amazon.com homepage (1000 tags): +- 129 milliseconds
Five times the Amazon.com homepage (5000 tags): +- 798 milliseconds



As you can see there is not much performance difference. Especially when you keep in mind that every time I ran my test page I got different results. With a page of 5000 tags it could run as fast as 481 milliseconds or as slow as 931.
Code crafting
The first test I did with the pure Javascript code gave different results because of a inefficient routine. It ran about 1/3 slower in the 1000-tag page and 4 times slower in a 5000-tag page. After consulting a colleague I was able to find a more efficient routine that could match with jQuery.
Conclusion
I think a lag of about 200 milliseconds during a page load with a 1000 tags can be acceptable. Especially since a web page of 1000 tags is already a large website to my standards. Most websites I develop have about 300 tags a page at best. If you want to use this hack, I guess it's best to test the script in the largest pages of the website. The gain isn't that spectacular: just support for :first-child. But on the other side it could really make your life as a web developer just a bit easier.
You might be tempted to patch other shortcomings of IE6 with Javascript. Don't start coding, but consider the IE7.js-script. But I must say up front that I don't have good experiences with it. The script works good in small pages with small CSS files, but you'll experience serious performance issues with medium or large websites.
Putting it in perspective
Chrome 4, by the way needed just 37 milliseconds to run the Javascript in the 5000-tag page. That's 20 times faster then IE6.


Related posts:
Alternative for :nth-of-type() and :nth-child()
For the sloppy clickers
Too advanced CSS selectors
How to overcome the limits of CSS in Internet Explorer 6

Test: Popular professional fonts as webfont

Wouter Bos — Sat, 23 Jan 2010 23:04:43 +0000

Why testing popular paid fonts?

I wanted to know how fonts that are popular with designers would look like on the web. Can you just convert those fonts to a webfont and put it in your website? I had mixed experiences with free fonts. But hey, they’re free. Maybe the those fonts you paid a lot of money for can do the job.

When designers realize that web browsers can load any font, they will try to push the limits with trying new fonts and web developers will certainly be pressured to convert a Gill Sans or Garamond into a webfont. License or no license. Especially since they are able to create fonts that contain just a subset of the original characters. That makes it unfit for people who hope to get a professional font for free by just downloading the font file from a website.

The test procedure

Please don’t pin me on not having the right Helvetica or Garamond. I’m not familiar with the subtleties between different version and foundries. I converted the selected fonts with Fontsquirrel’s fontface generator. The result is viewed in the following browsers:

Firefox 3.5.7 or 3.6 RC1 on Windows Vista
IE8 on Windows Vista
IE6 on Windows XP
Safari 3.12 on Mac OS X Leopard. Since I don’t own a Mac I used the service of Browsrcamp.com.

Fontsquirrel generates a preview text in different font sizes. I used that list of predefined font sizes as my check list. So I tested these font sizes:

9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

As you see there are enough other font sizes that might work as webfont. This test is not intended to be absolute and complete. I want to see how professional fonts behave as webfonts and what the typical font render problems are in browsers.

Helvetica

Definitely an all-time favorite. Apple computers have a Helvetica installed by default, but Windows does not. The Helvetica that I used for this test renders reasonably. Check out the screenshots for Firefox, IE8, IE6 and Safari. I also have the screenshots of the italic fonts for Firefox, IE8, IE6 and Safari. There are enough rendering glitches, though:

Some chracters are combined in Firefox (Windows Vista) at 11px.

The kerning of the 'e' is off in IE8, Vista at 15px.

Some characters seem to have a cap at font sizes 14, 16 and 18px in IE8 Vista.

Another kerning problem: the top is cut off in IE8 at smaller font sizes.

IE6 on XP SP3 is doing better than IE8 Vista, but vertical lines are over-emphesized at smaller font sizes and the text is very grey.

Looking in all four browsers, we get this list of usable and unusable font sizes.
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Garamond

Screenshots of Garamond in Firefox, IE8, IE6 and Safari.

There were lots of Garamonds to choose from. Don’t pin me down on not having the right Garamond of the right vendor. The errors that I encountered here are of more importance than the difference between different Garamonds.

With Garamond we can clearly see the strange font rendering that can happen in Firefox It’s almost as if it tries to add some creative touch to the font and fails. Take a look at the images below. Some characters are very different from the original font design, not? These rendering oddities also occur with the type Fontin Sans, that’s used on this website. It means that I cannot use some font sizes because some characters look weird.

Firefox PC: the character 'q' in different font sizes appear very different from each other.

Firefox PC at font size 13px: note the odd 'g' and the uneven distribution of space in the 'm'.

IE8 is even worse, Mostly because of bad kerning, I’d only use this font if the size is 48 pixels or larger. Look at the images below to see what IE8 does with text in large font sizes like 36px and 60px.

IE8: Because of bad aliasing and bad kerning the 'e' even looks bad at a font size of 36px!

IE8 again: Although I think it's more or less acceptable, the capital 'T' definitely needs more anti-aliasing at the top.

Garamond file size

My Garamond font file is very large to be a webfont by the way: 343Kb. That really asks for removing some characters. If I omit support for Greek, Coptic and Cyrillic, I can scale the file size back to 112 Kb. If I choose to only support Basic Latin, Latin-1 Sup, Currency Symbols and Punctuation, I end up with a file size of 82 Kb. Then you’ll have just one font style of the font family. If you want to have text in Italic, you have to double the file size.

Garamond font size

If you want to use a Garamond, you’ll have to use a much larger font size. That’s because the height difference between uppercase and lowercase in a Garamond is larger than the standard Arial. You need a 16px Garamond to get lowercase text that is of equal to that of a 12px Arial. In case of Helvetica it’s 13px by the way.

So we get this list of usable and unusable font sizes:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72:

Dax

Screenshots of Dax in Firefox, IE8, IE6 and Safari.

Dax is, to my surprise, doing a pretty job as a webfont. Almost no strange kerning in IE8 and almost no creative font interpretation in Firefox. For some reason are font sizes 21 and 24 bad for all characters, but other font sizes are doing well with the exception of a few characters.

Firefox 3.6 PC: FF and IE8 both have trouble with the diagonal line in the 'e'. At various sizes it looks like a staircase.

Firefox 3.6 PC: Both IE8 and FF have trouble font size 21 and 24. Note that the lines do not always have the same thickness.

So we get this list of usable and unusable font sizes:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Gill Sans

Screenshots of Gill Sans Regular in Firefox, IE8, IE6 and Safari.
Screenshots of Gill Sans Bold in Firefox, IE8, IE6 and Safari.

Gill Sans Regular looks relatively nice. There are enough font sizes to choose from. Let’s focus on some rendering issues:

Another example of the 'creativity' of Firefox. You see some text in font size 16 and 17. Note the 'o' and 'e' on the top line that look like flat ellipsis instead of perfect circles.

IE8 Vista: Font size 14 looks nice. Except the captital 'T', which is too thick.

IE6 on XP SP3 does too much anti-aliasing, so that text in small sizes become almost a grey blur. Using a bold style can really make a difference.

Usable and unusable font sizes for Gill Sans Regular:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Usable and unusable font sizes for Gill Sans Bold:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Bodoni

Screenshots of Bodoni Book in Firefox, IE8, IE6.
Screenshots of Bodoni Book Italic in Firefox, IE8, IE6.

IE8: Even at large sizes the small lines tend to be troublesome. Note the broken lines in the 'o', 'e', 'p' and 's'.

The grey blur of IE6

Bodoni renders badly. As I expected. The thin lines in serif fonts prove to be troublesome in webfonts. This is mostly due to the anti-aliasing of IE8 that is way too sharp. The italic font style has a even worse legibility.

Usable and unusable font sizes for Bodoni Book:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Usable and unusable font sizes for Bodoni Book Italic:
9 10 11 12 13 14 15 16 17 18 21 24 30 36 48 60 72

Conclusion

Phew! that’s a lot of data. So what does it all mean? Well, for starters we now know for sure that you have to check your font in different browsers and eliminate the font sizes that render badly before you start to design. This and other tests seem to show that it’s best to only use simple, sans-serif fonts. That’s because variation in thickness and diagonal lines prove troublesome in webfonts. Especially in IE8 on Vista because it’s very sharp anti-alias. It’s so sharp that the fonts look jagged.

Fonts in Firefox don’t look jagged and look great in very large sizes. The trouble is the ‘creativity’ in the rendering. Characters can be wider, smaller, higher or lower than intended. In some cases it can change the complete look of a font.

The anti-alias in IE6 on Windows XP SP3 is in most cases way to strong. Most black text is printed grey at smaller sizes. But in some cases the vertical lines of characters exactly fit in one pixel, which results in a pure black line in a grey text. Not good.

And Safari? You haven’t seen me talking about Safari. That’s because the font rendering in OSX is all you could wish for. That doesn’t mean I have seen some rendering issues, but they are of a complete other order and are insignificant compared with the troublesome rendering on Windows. Font rendering in the PC version of Safari is by the way just as bad as IE, if not worse.

I recently tried Typekit and seen webfonts on Ascenderfonts. The selected fonts look most of the time way better than you can do yourself. So I guess that webfont services is logical option, from both legally and legibility standpoint.

Webfont pitfalls

Wouter Bos — Tue, 19 Jan 2010 22:30:28 +0000

Selecting a font

One of the first pitfalls you can fall into when using webfonts is that you find fonts that seems nice but aren’t usable. That could be for a number of reasons:

Huge line heights: Some (free) fonts have lots of space above and below the type. You have to give the text something like line-height: 0.8em to make it look good. But users with Chrome or old browsers will not see your website. Instead they will see lines of text in Arial on top of eachother.
Legibility: Many fonts are only useful as a heading. That’s because font rendering on Windows is far from perfect. Especially at small font sizes. If your font isn’t readable at 11px, think twice if you want it for your body text. Please keep in mind that fonts in IE are even less legible.
Don’t trust Photoshop: Photoshop cannot emulate the bad aliasing that can occur in browsers, so don’t comfort yourself when everything looks fine in Photoshop.
Test in browsers: Pick the fonts you want to use and test it in different browsers. I like the free font-face service of Fontsquirrel because it not only converts the fonts to webfont format, but it also generates an HTML-file with the webfont in different sizes. Just open the page in various browsers and compare. You can check which font sizes have a good legibility. Be sure to check IE and Safari on PC because they are the worst when it comes to font rendering.
Be wary of free fonts: I use free fonts, but you really have to pick the right ones. Some have for example problems with legibility.
Be wary of commercial fonts as well: Users can download your fonts. So if you use a $200 dollar font, you make it freely available. In theory you could make a new font with just a subset of the original. That would make it less desirable to download, but also less usable and it’s still not legal at all.

Conversion options

Fontsquirrel has some options when converting fonts to EOT, the only font type that IE supports.

Hints: Hints help the anti-aliasing engine with it’s work by giving … well, uhm … hints on how to do that. Hints tell what pixel should get which color in order to create the effect of smooth lines. If your font has bad hints or none at all, you could auto generate them when converting. It can make a difference. Hinting is done fully automatic though, so you could expect glitches like having an i without a dot. Those errors occur mostly at small font sizes, so if you use the font in headings it should be fine.
Subsetting: A font can be as small as 20Kb, but also as large as 200Kb. Multiply that number with every font style you want to use like italic and bold. My weblog loads 4 font files of +- 25Kb. For IE the font files are even larger: 4 times 70 Kb. You can limit the file size by removing all the types you won’t use like Arabic or Chinese.

Setting up the font-face right

The right @font-face syntax: Writing the font-face code isn’t hard to do. But what you really need to be sure of is that it works good for all browsers. After I implemented webfonts in this blog, I discovered that Firefox loaded both OTF and EOT files, although it doesn’t even support EOT! Paul Irish has a nice article about the various font-face options and concludes that there is only one good syntax. That’s the one below:
@font-face { font-family: 'Graublau Web'; src: url('GraublauWeb.eot'); src: local('Graublau Web Regular'), local('Graublau Web'), url('GraublauWeb.otf') format('opentype'); }
Cross domain webfonts: I discovered that Firefox is pretty fussy when about the location of fonts. This can save you an hour of frustration.

Of all the errors I made, the biggest one was the idea that you can grab any font, use it in your website and be sure that it renders like you would expect in Photoshop. It just doesn’t. There aren’t much fonts that render well at 11 to 14 pixels. This blog used the font Fontin Sans for all text. Now I scaled it down to just the logo and the major headings. All other text is “just” Tahoma/Geneva.

Implementing font-face cross domain

Wouter Bos — Tue, 12 Jan 2010 21:13:59 +0000

I’m still in the middle of a redesign of my personal weblog, but I’m glad I got the font-face working. It was a hard nut to crack. The source of all the trouble was that Firefox would load font files from other domains. Although the domain restriction isn’t making things easier, it is sort of sensible.

Internet Explorer is the only browser that supports EOT, a font format that has digital rights management. That way you can make sure that your $200 font isn’t downloaded and used by everybody on the internet.

But like I said: IE is the only browser that can understand that file type. So Mozilla apparently implemented some sort of protection against font hijackers: It will only accept fonts from domains that specifically allow fonts to be downloaded. In case of Apache you have to add the following code below to the .htaccess file. I found it on Open Font Library.

Header set Access-Control-Allow-Origin "*"

This does not help you prevent people from stealing your font, but it will protect you from web developers who want to add the URL to the font on your domain in their font-face declaration. It’s not really a solution if you ask me. It seems more like a gesture to the creators of fonts.

It appears you could replace the asteriks with the domain of your website, but in my case (http://electricspace.blogspot.com/) did not do the job.

Do you create your design in Photoshop or Notepad?

Wouter Bos — Wed, 06 Jan 2010 23:22:14 +0000

Recently Meagan Fisher published an article in which she discusses an alternative way to present a web design to a client: Don’t emulate it in Photoshop, but build it in HTML and CSS. There are some advantages to it. A client can see more than just the design. He/she can also see:

Behaviour of the fluid design
Interaction like hovers
How the website looks in different browsers

On top of it, she also mentions some disadvantages of using Photoshop:

It crashes, leaving you with hours of work lost.
Font rendering sucks

Photoshop is still king

Although creating a website directly in HTML has it advantages, I think designing in Photoshop is better in most cases.

Photoshop is faster

Yes, a simple design could well be created directly in HTML. But not all designs are simple. Changing a background color is easy in CSS, but dragging columns around, changing or altering visuals and all kind of other alterations are quicker in Photoshop. Designs can change dramatically before it is finally approved by the client. Those changes are quicker done in Photoshop.

Photoshop is static

Being static isn’t not just a disadvantage. A static design is in fact helpful because it helps you focus on how a website should look like and not be bogged down by browser incompatibilities. This too gives you extra speed in designing.

Photoshop is versatile

Just because CSS can do stuff like round corners and text shadows in some browsers, doesn’t mean it has become a designing tool. Photoshop can do more than just that. When designing in HTML I start to think too much in the constraints that both HTML and CSS have. In Photoshop I have much more design choices. Because of that I’m able to think more out of the box.

Crashes and font rendering

I was suprised that Photoshop crashes are mentioned as a major problem. I consider Photoshop as a very reliable product. The only problem is that saving can take a while, so not everyone saves regularly. If you don’t save regularly you’re asking for trouble. Even with stable products.

The issue with font rendering is indeed a problem, but that’s more an issue for designers. Clients don’t even know it’s an issue. They’ll only notice differences when they’re dramatic like with webfonts. Just compare this weblog between Apple Safari and IE on the PC: it’s hard not to see the difference.

My preference

Since I’m a web developer I ought to be tempted to skip Photoshop and start coding right away. But that’s not the case. I designed my blog twice last year. In both cases I chose to do the basic design in Photoshop. Only when I was happy with that basic design, I started developing and added extra elements on the fly. The current design of my blog could just as easy be built in HTML/CSS from the start, but I’m convinced it’s better to work in Photoshop first.

Alternative for :nth-of-type() and :nth-child()

Wouter Bos — Mon, 04 Jan 2010 21:17:14 +0000

View demo

One thing I really like about jQuery is the ease by which you can select the nth item of a list of items like this: jQuery("ul > li:eq(3)"). In CSS you would select an nth item like this: ul > li:nth-of-type(3). The problem is that :nth-of-type() is not supported at all in Internet Explorer. IE9 will support all CSS3 selectors, including :nth-of-type(), but by the time IE9 is a mature browser, Webkit and Gecko-based browsers are be able to do everything except your dishes.

So if you want to make an exception for, say, the third menu item, you have to either add a class to that menu item or select that item through Javascript. But if you don’t care for IE6, there’s a reasonable alternative:

ul > li:nth-of-type(3) equals ul > li:first-child + li + li.

Although both selectors are different, they do select the same element. But the first is not supported in IE and the second is. From IE7 and up! Sure, it’s not feasible to select the 100th item in a list, but not all lists are that long. And you can always use Javascript as a fallback.

This alternative selection method is by the way by no means equal to :nth-of-type(). With :nth-of-type() you can make a cool zebra striping without the use of Javascript.

And finally, as suggested in the title, there is also a way to handle :nth-child(3) in an almost similar fashion:

ul > li:nth-child(3) equals ul > *:first-child + * + *.

Blog redesign

Wouter Bos — Sat, 02 Jan 2010 23:53:27 +0000

The last few days I was busy redesigning the website. I was not happy with the original design.

The menu on the top right was large and clunky. Because of that it didn’t leave much room for more links.
The ‘logo’ on the top left did not feel like a real logo mainly because it was … well … just not designed well.
The shadow effect on the columns looked cool, but because it was made with PNG8 images instead of PNG24, it wasn’t possible to add an background image to the page.

What I did like was the scalability of the website. you could as easily view the page on your (i)phone as it would be on your large, wide computer screen. I dropped support for mobile phones. There are lots of Wordpress plugins to cater the mobile devices. I have to dive into that some time. For now anyone with a mobile device can grab the RSS feeds.

I still have to fix a few styling glitches but I thought the design was good enough to make the switch. Here are the most important aspects of the design:

Use of rgba as background color. This makes it possible to set opacity for just the background instead of the whole box. rgba is not supported in IE, so you will have a solid white background then.
Using opacity in the columns makes it possible to use large backgrounds. That gives me a reason to pick up my photography.
The use of webfonts. This was something I was eager to use. This is something designers and web developers alike have been waiting for. The implementation isn’t perfect, but it looks well in Firefox and on the Apple. IE and Webkit on the PC still need some tweaking. I’ll go in to more detail in an upcoming article. For now I’ve been glad to be able to experiment with a real web site instead of running some tests with webfonts.
Less data: I removed irrelevant data where I could. It’s most apparent in the list of articles on the homepage where I removed information like categories, tags and dates.
Links become visible with an underline when a column is hovered. This will make the website look less crowded. It’s a bit like the folder tree view in Vista’s Windows Explorer: you will only see the folding icons (the plus and minus icons next to the folders) when that section is active.

There are some things I have to do:

Make a logo that is suitable for creating a favicon
Tweaking the fonts for IE & Webkit on PC.

No related posts.