CSS: The Good Parts | Hacker News Reader

CSS: The Good Parts

pixelstech.net

31 pointssonic000213 comments

The original article is here: http://www.impressivewebs.com/css-the-bad-parts/

I don't know if this was blogspam or what.

I think you meant http://www.impressivewebs.com/css-the-good-parts/

Edit: I noticed that both articles have the same author.

Good catch, yes I did! I was typing that on my phone, and had the wrong thing in my paste buffer. Both articles are worth reading though.

Thanks for linking to my original post (and below). At least the scraper version does link back to my original, so not a complete loss. :)

I had expected a small, opinionated book on CSS.

Instead, there's a decent article.

Same. I gleaned quite a few little tid-bits from this article. I started reading and was able to branch off with the provided links to get more in-depth information.

A good article with useful links, as was his "bad parts" article. But I'm puzzled by his complaint about CSS commenting style. In Vim, using the tcomment plugin, I can comment out whole or partial lines with a few keystrokes, in many languages, and Vim knows what language is in the buffer and uses the correct comment syntax, so I don't even need to remember it. Other editors and plugins have similar functionality. It sounds like the author is commenting/uncommenting by hand. As is so often the case, using the right editing tools makes your life better.

Having a tool to make something easier is one thing. But the commenting style complaint is valid. I am not puzzled by the complaint. It would be nice to have it work as he described so you would not have to rely on the tool to be there.

Note that attribute selectors have really terribad performance on complex pages; avoid them if you're writing a single-page web app.

(actually, most things have terribad performance on complex pages, including inheritance selectors, :nth-child, sibling selectors, and tag selectors. Basically, the only selectors that are fast in CSS are IDs and classes with no inheritance. Wooo.)

We did some benchmarking. It's easier to use jQuery to do the DOM traversal than it is to let CSS try and figure it out in most cases when you're using inheritance selectors.

That statement is too broad to be correct: modern browsers have had work optimizing selector performance (see http://calendar.perfplanet.com/2011/css-selector-performance...) and you really need to measure before drawing conclusions, particularly when the alternative of cargo-culting less semantic, harder to maintain code has its own costs and doesn't get as much performance attention as browsers do.

Since there are are now CSS profilers for Chrome, WebKit and Opera (see http://perfectionkills.com/profiling-css-for-fun-and-profit-...) you can also make the better comparison: your actual site.

Examples: http://stevesouders.com/efws/css-selectors/csscreate.php?n=1... http://stevesouders.com/efws/css-selectors/csscreate.php?n=1... http://stevesouders.com/efws/css-selectors/csscreate.php?n=1... http://stevesouders.com/efws/css-selectors/csscreate.php?n=1...

All four are very close in time in Chrome and Firefox - within 10ms or so. In all permutations of this, what really makes the most difference continues to be the question of how quickly the browser can narrow the set of nodes under consideration, which usually comes down to how well your markup makes expressing relationships natural rather than syntax tricks.

Quick and dirty one-line comments should be used very carefully. Before a block it can break the selector, so no styles get applied.

not a very long list i see..

Reply on news.ycombinator.com