Live data from Hacker News

A Shocking Truth About CSS

blog.twoalex.com

61–70 of 70 posts

Re: A Shocking Truth About CSS

#61
post #19

I do not like their blog gimmick.

FWIW, the post is a slightly cleaned up version of an actual conversation I had with my husband. (I'm K, he's M.) It's not a format I'm likely to reuse (or have used before), but it fit the occasion and captured very well our feelings of surprise at learning how CSS parses selectors.

Plus, it's always fun to try out new formats, even -- or maybe especially -- if they don't stick.

Re: A Shocking Truth About CSS

#62
post #48
post #43

Earlier quoted context omitted.

It's a little trickier when you do it left to right. Suppose you have a DOM tree like this: div #alert - p, p, p - div #alert - p [lots of children] - p - div #alert [lots of children] [right to left] In order to find all Ps with an #alert parent, you first get a set of all paragraph elements. Most likely a list of all paragraphs is kept in memory, so it can be enumerated quickly. Since DOM trees are generally well b…

Your examples aren't valid HTML, so that approach is fine for quirks mode. But what about valid pages that declare a DOCTYPE? Shouldn't those be parsed from left to right, so the first matching ID that is encountered wins (with any other matching IDs considered errors and disregarded)? OT, this was one of the problems XHTML was supposed to solve, since it was originally assumed by many that pages that weren't well-fo…

that approach is fine for quirks mode

And it is also fine in standards mode - double win.

Re: A Shocking Truth About CSS

#64
11:44:33 AM Alex K: that makes it sound like it may not be worth huge optimization? 11:44:46 AM Alex M: no, not really 11:44:56 AM Alex M: I’m a purist though 11:45:18 AM Alex M: so this makes my world

Last two lines scares the hell out of me.

Re: A Shocking Truth About CSS

#65
post #45

I don't want to read several pages of badly spoken chat english to find the conclusion. Could someone be so kind and explain what the shocking truth is?

That tables really are the best, CSS is good for changing fonts all at once though. I read it all for you so don't worry about double checking.

Re: A Shocking Truth About CSS

#67
post #10

The "Two Alexes" are just discovering (Feb 2010) what Steve Souders explained in detail at http://www.stevesouders.com/blog/2009/06/18/simplifying-css-... [which is probably the site you want to visit on "How CSS strategies affect site performance"] (June 2009).

Being "scooped" by a mere 6 months, on a 10 year old technology doesn't really make their realization dated. It's new to me, and I bet it's new to most news.yc-ers.

Scooped by 10 years on a 10 year old technology, not 6 months. http://news.ycombinator.com/item?id=1180429

Re: A Shocking Truth About CSS

#68
post #3

(from the header:) The Two Alexs Alexes? Alex's? Alexi? Alexim? In hackanonical form, Alexen. As in oxen, vaxen, boxen.

Take Alex's, Alexi, Alexim, Alexen, and boxen out back to be euthanized along with the awful virii and anything else that would lead Cory Doctorow to chortle while typing.

Hackanonical, however, is without flaw. It should be in the name of this site!

Re: A Shocking Truth About CSS

#69
post #65
post #45

I don't want to read several pages of badly spoken chat english to find the conclusion. Could someone be so kind and explain what the shocking truth is?

That tables really are the best, CSS is good for changing fonts all at once though. I read it all for you so don't worry about double checking.

Thanks!

Re: A Shocking Truth About CSS

#70
Reminds me of how you may optimize your javascript DOM/style manipulations to avoid re-calculating the styles too often. It was mentioned in this Google I/O session on GWT performance: http://www.youtube.com/watch?v=q9hhENmVTWg#t=32m38s (slides located here: http://code.google.com/events/io/2009/sessions/MeasureMillis... )

This is where Speed Tracer comes in handy ( http://code.google.com/webtoolkit/speedtracer/ )

Post reply on HN