[analyst74]

I don't completely agree with author's opinion.

I think the Facebook Way (tm) has its pros, but using page-level specificity is a great way to avoid specificity hell.

To be more specific, for a site with vastly different pages, it's best to have page or section level class that limits the scope of each css definition, so the person making change to one section of the site will not accidentally break other pages. Also, with little base style, there is less need to override styles with more specificity.

For such a site, CSS like this tend to be easier to maintain:

#home-page h2 { /* home page title styles / }

.news-item h3 { / news item title / }

#widget-page h2 { / widget page title / }

.widget-item h3 { / individual widget title */ }

[protonfish]

I agree this is a better way to do things, but if we want to be page-specific, why not use separate style sheets? I know we are supposed minimize the number of http requests but is having 2 external style sheets (1 for global styles and 1 for page-specific styles) really too many? It will prevent parsing every style for the entire site on every page load whether the page needs it nor not, plus decrease collisions and other maintenance problems caused by too much CSS in one bucket.

[Jormundir]

I think you both have missed the point.

When you code CSS the "facebook way" :(, you don't have to worry about bleeding effects.

Want your h1 to have a margin of 35px or whatever? You give it the class large-margin or something. You don't have to worry about affecting other h1's, because they have the classes specific to the way they should be styled.

When you style in the way the root comment is suggesting, you do have to worry about bleeding styles, because selecting h1 tags in one section may also style an additional h1 tag you didn't mean to style.

The whole point is: don't select specific elements to style, rather, create classes of types of styles, and, when creating an element, select the classes of styles you want the elements to have. This way you don't worry about bleeding styles, each element has the classes representing how they are supposed to be styled, and you will never accidently over-select elements.

[Jormundir]

I see I slightly missed the root commenter's point myself.

There's a trade-off of consistency across your site. I personally think it's not a good design choice to encourage different pages to have different style sheets.

Anyways if you want more specific styles, don't create specific selectors, instead create more specifically named classes so you don't lose the positive properties of the facebook way (Can we please get a better name?).

[analyst74]

My examples must be misleading, I'm not against creating classes.

All I'm trying to say, is that in some cases (i.e. when you only need a particular set of styles for a single page/section), limiting the scope of those style definition can help dealing with specificity hell / bleeding styles, and make the application more maintainable.

Obviously, this is a trade-off, a big one if you want your site to be consistent across pages. But there will be occasions where one or more page of a site/app is vastly different from other pages.

[Jormundir]

Selecting element types rather than creating new classes is what causes bleeding styles.

[protonfish]

Until you get class-name collisions or your classes are applied to elements by other developers without you knowing. So you create more unique classes and every element ends up having 12 classes applied to it. Classes are no solution to bleeding styles.

[obviouselk]

I don't why you guys refer to it as the "facebook way", the name you're looking for is right there in the submission title: a way to write better css. And facebook is host of one example of it.

[analyst74]

Breaking styles into multiple css files is definitely the natural next step, a necessary one when your css files are growing past thousands of lines.

If performance (minimizing http requests) is not a big deal, then that'll be end of story. But if it unfortunately is a problem, current tools generally support combine/minimize them into a single file, but not dynamically choosing based on page requested.