Selectors
In both Firefox's CSS engine and Sizzle (jQuery's css selector engine), rules are evaluated from right to left. The right-most piece of the selector, called the key, is matched first. The other end is called the anchor. From these groups of elements, the rules to the left of the selectors are applied in order. The major source of slow CSS application is inefficient key selectors. Consider:
#facebook div ul li a.namelink { color: green; }versus:
#facebook div ul li a { color: green; }The first is very fast, especially for cases where there are only a few a.namelinks in the page. Although the CSS engine has to verify the descendant rules in the selections, the amount of DOM nodes in the key's search space is small enough where the speed difference of the deep selector and a shallow one will be negligible.
This is how CSS selector engines work in general, but Sizzle makes things a bit more complicated, since selections are made against the DOM using whatever methods the DOM provides. getElementsByTagName appears to be much faster than any method of getting elements only by class, so $('.stuff') is slower than $('div.stuff') since the DOM can use getElementsByTagName to filter out the search space first. id'd elements should be unique, semantically, and getElementById is one of the cornerstones of any DOM implementation, so it's generally extremely fast.
Because of these types of issues, it's often more efficient to chain rules with $.fn.find than to use one selector. Until a recent changeset that targeted #id anchored selections, it was much faster to do $('#id').find('a'); than $('#id a'); this is special cased, but for instances where the anchor isn't an id it's better to do the chained find/not than to have a complex selector.
To examine how a variety of JS selector engines manage against a host of different selectors, you should try out the slickspeed page.
tl;dr: CSS Selectors should have efficient key selector portions, and jQuery selectors should include the element on classes (not IDs) to enable use of getElementsByTagName.
New HTML stuff
We're already using most of the safe 'new' css features, like drop shadows, border radii, and text shadows. Some pretty random thoughts about HTML5 and some newer HTML/CSS stuff coming out:
We might want to think about incorporating some of the new form types, especially email, which gets special iPhone treatment.
If we can find a way to test for HTML5 video (yet?), at least Facebook videos offers an mp4 link that we could use to embed rather than Flash.
The text-overflow rules in css might become important as we move towards localization; right now all of our copy is specifically designed
- A lot of the transitions will probably be smoothed over in js libraries; they'll make that type of eyecandy faster on good browsers, but we wouldn't really want to bother with them ourselves (unless we end up writing such a library). Other effects (skew, rotate, transform) just don't seem to make sense outside of tech demos or
.