Hacker News new | past | comments | ask | show | jobs | submit login
What the Heck Is CSS Specificity? (designshack.net)
55 points by codingthebeach on Oct 13, 2012 | hide | past | favorite | 20 comments



And that, my kids, is why CSS sucks. Cascading is the most stupid "feature" ever. Just imagine that we could've had classes with inheritance instead, which would reduce time spent on debugging the selector mess it is now; browsers would also parse the styles much faster. And then we could build modules or components, themes and frameworks on top of that. Add a semantic constraint engine with parametric styles (so I can say if I want two elements to align in some way), support for calculations, and coding CSS would be fun instead of frustrating. One can dream, I guess...

A much better rant on CSS general sulkiness: http://www.raizlabs.com/blog/2006/09/25/ten-reasons-why-css-...


Just because you don't like a feature or design choice doesn't mean that the entire language sucks. If used right, cascading can be incredible powerful. If used poorly, it's a total PITA.

You could make similar complaints about insert your favorite language/framework here.

If you want to make webpages, you're pretty much stuck with CSS for the foreseeable future. Better to promote best practice rather than writing off the entire language.


You are right. A single feature isn't a reason to think that an entire language sucks. But in this instance we are talking about a defining feature of the language. They're called cascading style sheets for a reason. I know we're stuck with it for now, that's why I'm ranting. My god, this is like PHP in the 90s, if I rant against something, then "I'm using it wrong" or "I'm too stupid and don't understand how great it is". And in the meantime all the CSS "gurus" are teaching people that to centre an element it is perfectly normal to write { left: 50%; width: 400; margin-left: -200px }. Even worse, they squabble over which way to clear floats is the correct one, when the truth is we shouldn't be having to do this in the first place.


The tech community should have a discussion about the best way to move forward with CSS, but it will probably turn into this: http://xkcd.com/927/

Like it or not, CSS has legacy support built into millions and millions of devices that cannot be easily updated. Newer versions can come forward, but more likely than not, the best thing to do would be to build on frameworks such as LESS (or one of it's cousins) that allows you to code in a meta language. Combine it with some static analysis tools and you can create a system that warns you when you cascade too much (for some value of too much) and help keep you sane.


I guess that is why the web is so great, despite of all the technical problems. There was a good post recently about OOCSS and SASS, I think it is a good approach for now.


For what it's worth, I have used CSS for years without knowing anything about specificity and never had to debug (more than a few seconds) anything related to specificity... If you actually have to use the formula to find out the specificity of a selector, I'd say there's likely something wrong with the way you code CSS.


To avoid too much hassle, I once decided to only use classes. So instead of having #header, #nav and #footer, I had .header, .nav and .footer.

When learning CSS, we're told to use id's whenever we're targeting a unique element that isn't meant to repeat itself, hence the #header. So we apply this rule without looking too much into it, thinking it's wrong to use a class for unique elements like that, when it's actually not.

You just lose some readability in distinguishing unique elements from repeated ones, and you need to avoid using the same unique element twice. But ultimately your styling works the way you expect it to, and leave id's for anchors and JavaScript.


The 10-100-1000 factor is in a large base, shown recently in most browsers to be base-256. http://news.ycombinator.com/item?id=4388649


This is one of the last things I figured out when I was learning CSS, but it's arguably one of the most important. Once you realize that it exists, all of a sudden any new CSS you write will shrink and you'll understand all those weird quirks you were seeing but not understanding in your giant stylesheet.


Here's a nice poster demonstrating CSS specificity with fish. http://www.standardista.com/wp-content/uploads/2012/01/speci...


I've always had a soft spot for Andy Clarke's (much older) CSS Specificity Wars poster: http://www.stuffandnonsense.co.uk/archives/css_specificity_w...


Clarke's lacks inline style and !important.

Sure, they should be used with care, but !important is actually really useful in responsive webdesign.


Pretty solid find. Great for explaining to newbs.


> h2::first-line

…I've never seen this notation. I've always seen pseudos with just one colon.

Some quick testing in Textmate reveals that this does, indeed, work, as does the single colon I've always been using. Triple colons don't work.

And this only works for pseudo elements; pseudo classes only work with single colons.

At least in Webkit; I didn't bother checking my simple test-case in Firefox, Opera, or IE.

Huh.


That's the spec as of CSS3, pseudo elements get ::, pseudo classes get :.

Practically speaking browsers will accept : for everything, possibly forever.


I learnt a new thing! And will probably never use it until browsers start being picky about it.


On a similar note, I'm currently in the planning phase of building a "specificity calculator" as a bundle for TextMate. It will mostly be targeted towards complicated CSS files and the people who create them but I imagine it will also be helpful for people new to CSS. Would any of you guys have interest in such a bundle?


Specificity PSA: Don't use !important unless you absolutely, positively have to.

Recently I've run into WordPress themes where the author doesn't grasp the cascade and resorts to using !important. Widgets embedded on third-party sites are about the only good use I've seen.


"Elements can never beat a class selector, even if you pile them on"

Uhh.. what about classes? Can you pile classes on to beat ids?

Can you pile ids to beat inline? (Well that kinda doesn't make sense).


It appears that 256 classes can override an ID.

http://news.ycombinator.com/item?id=4388649




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: