Specificity CSS property for W3C?

I’m sure everyone who does CSS a bit has probably had to plan out their webpage and think about CSS specificity and how they will combat certain cascading elements. Some planning is involved…

I just thought about this; wouldn’t it be neat if there were a “specificity” property? Numeric values. It’d make it easier to not have to worry about the cascade. I don’t know the finer details (just popped in my head) but what’s your guys’ take on it?

E.g. this.

body{/crap/} is normally worth 0001, or “1”. You could set specificity:100 and make it worth an ID value (0100)

It would end up much the same because you may have set something else further down the tree to a higher value. In the end it would be no different to !important because even though they win out you may still have beaten them with other !importants . :smile:

I never really run into specificity issues in my own code because I avoid ids and long descendant selectors (where possible).

Yeah not many people have the same…“methodical” approach to selector use though. I hate long selectors personally; takes a while to type and it just looks bad/causes issues down the line.

I’ve seen a lot of code examples wehre people just type whatever they want and it works…but it’s sloppy. There’s no normal structure to many peoples code.

And yeah, I was thinking about it for the past hour. My initial thoughts were that it would make it so you wouldn’t need any long descendant selectors but I’m having trouble thinking of a way around this or what the default behavior would be if it was missing, etc.

This was more an idea of, hey, there is

html body div#container #opener h1.title{}

That calculates out to be 0213 if I did my math right. I could do

h1.title{specificity:0214;/whatever/} and it’d save yourself.

It’d also help avoid !important. !important is supposed to be “Gods hand” making CSS work. It’s supposed to make it almost always work. Yet it’s kinda being abused today…

This was to try and save !important for when you’re actually in NEED of it; not as a copout.


Whether this is actually needed as a support for !important? Probably not. Perhaps this was a stupid suggestion but I thought about it in the lunch line so I wanted ti get it in words before I lost track of it. Wanted to see what everyone had thought of it :wink: .

!important just adds 1000 to the specificity…this is sorta an in-between between !important and not.

Edit2 - also maybe to override specificity (e.g. and not have to make a slightly longer selector to override another !important?)

It’s good to think about things like that because it makes you re-evaluate what you do and how to make it better. Quite often when you suggest something new you relaize that it worked the way it does for a number of reasons that make it work best the way it is (not always the case though I agree).

Specificity can be a pain at times but in the end only one rule can win out so the problem will always exist as to how that mechanism can work.

Sometimes I often think that perhaps the latest rule in the stylesheet should win out because that’s the one you were expecting to change the layout with and then you don’t need specificity at all. e.g. if you said at the top of the stylesheet body#body (background:red) but then half way down the stylesheet you decide to change it then body{background:blue} should win out because that’s what you want :slight_smile: (I realize that’s too simplistic but sometimes what you first expect may have been a better way to do it).


Some enforced order is also a good thing. It defines a structure. Imagine trying to wade through someone else’s CSS code trying to find where s/he arbitrarily set the specificity of an element via a property change within the rule set!

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.