“table.foo tr td” and the other way would be “td.foo”, because so I can style more tables independent.

My intention was really to tell the parser… “you don’t need to go look at this section of the page, these are not the nodes you’re looking for” ;) … but I was fooling my self… it doesn’t do that at all, nor could it… this would only have a chance of working if you used the “child” selector and not the “descendant” selector… so I wonder what “table>tr>td.classname” as opposed to “table tr td.classname” would do (and then maybe “body>table>tr>td.classname”)… especially in a large document where there’s only 1 table. Only IE 5.5 and 6 does not support “child selectors”…

(The article is misleading as it seems to use the term “child selectors” where it should use “descendant selectors”)

Of course I could be wrong :)

I’d love to see techniques for speeding up stylesheets on large and complicated CSS structures.
It seems to me the only thing CSS optimisers know how to do is get rid of the added specifications… which to me was just aimed at minimizing file weight… but getting rid of something much more precious which was actual knowledge of where the style are to be applied (and where we do not need to look for them.)

Looks like a whole lot of wrong assumptions

I always felt that the more specific the selector rule, the worse the performance. It’s usually better to have a generic selector rule rather than a specific one.

Of course, that’s all anecdotal.

In his test for 20,000 dom nodes he says that it is very extreme–That’s great! I always ask myself, “How far can we push a web application to its limits in terms of user experience, functionality, and performance?”

Kudos to Jon for a good find.