>as an aside, i think it'll be really interesting to see how Doug
>working for Google [2] will effect their markup.
I don't know that it will that much. I was in Mr Bowman's full-day workshop
during webStock*. You can tell he's quite obsessive about things being real
neat & tidy - it comes through in his code and presentation very clearly - but
one thing he did mention is that Google tests applications in terms of
microsecond responses - both in terms of server processing and rendering on the
client.
He outlined that rules like
#main p em.special {
/* style here */
}
May be great in our stylesheets, but the browser ends up having to make
decisions like this:
1. Am I inside the element whose id is 'main'?
2. If so, am I inside a 'p' element?
3. If so, am I processing an 'em' element?
4. If so, does it have the class 'special'?
5. Ok, I'll apply the style rule here
Doug stated that in these type of cases, where microsecond improvements are a
big deal for *perceived* speed improvements (like the ones you've noticed with
Amazon et al) it's better to just write rules like:
em.special {
/* blah */
}
(two decisions)
Or simply
.special{
/*blah blah */
}
(one decision)
I guess that's why you're seeing inline styles - the browser then doesn't even
have to make a processing decision as such, it just applies the style rules
directly to the element in question.
Bear in mind that Doug was involved in the development of the UI for Google
Calendar, so the code you see there may be an indication of coding conventions
made for speed adavantages rather than just 'sloppy coding'.
Be interesting to see what comes of Doug's involvement....
* http://www.webstock.org.nz
******************************************************
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************
