7

I have came through this situation recently but unable to find 'Why'? Can anyone explain?

See the example below at: http://codepen.io/chriscoyier/pen/lzjqh

Jerry Jones
  • 761
  • 1
  • 9
  • 24
  • 2
    If you can find the link, surely you can find the explanation... it's literally plastered all over the Web right now. – BoltClock Aug 17 '12 at 09:16
  • possible duplicate of [Points in CSS specificity](http://stackoverflow.com/questions/2809024/points-in-css-specificity) – My Head Hurts Aug 17 '12 at 09:18
  • 1
    @My Head Hurts: Not really... that explains why the points explanation is flawed but it doesn't address the bug being demonstrated here. – BoltClock Aug 17 '12 at 09:21
  • @My Head Hurts: It looks to me that the accepted answer would answer this question too. That said it still doesn't make this question any more of a duplicate *or* that answer any less misdirected... – BoltClock Aug 17 '12 at 09:43

2 Answers2

11

This happens due to a browser limitation, and not a mistake in the spec or how browsers implement it.

The spec says:

A selector's specificity is calculated as follows:

  • count the number of ID selectors in the selector (= a)
  • count the number of class selectors, attributes selectors, and pseudo-classes in the selector (= b)
  • count the number of type selectors and pseudo-elements in the selector (= c)
  • ignore the universal selector

Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.

Concatenating the three numbers a-b-c (in a number system with a large base) gives the specificity.

Browsers have to store specificity values as integers for the purposes of calculation, and somehow a value of 256 causes an overflow depending on the browser. This usually happens with an 8-bit unsigned integer, whose max value is 255; adding one more causes the class-level specificity to somehow be "upgraded" into an ID-level value, making it equal to the ID in the cascade and thereby overriding it.

Community
  • 1
  • 1
BoltClock
  • 630,065
  • 150
  • 1,295
  • 1,284
  • I think this answer sums it up nicely enough. I was going to expand it, but see the question linked in the comments. I may move my answer over if there's a need to explain the disparity between the spec, and implementation details in browsers. – BoltClock Aug 17 '12 at 09:55
  • Begs the question of why specificity isn't capped at 9n. Is anyone really going to ever have more than 9 class, attribute or pseudo-classes featured in one selector? Being capped at 9, specificty score would only ever have to be stored in decimal and an infinite number of classes could never out-score a single ID, as `90` < `100`. – James Donnelly Dec 09 '14 at 16:07
  • 1
    @James Donnelly: As a matter of fact, Selectors 4 does state that implementations should cap specificity values and not allow them to overflow. – BoltClock Dec 09 '14 at 16:09
  • That's very interesting to know, I hadn't considered looking there as I'd assumed it would remain the same. Neat! – James Donnelly Dec 09 '14 at 16:10
  • @James Donnelly: Yeah, in fact, it was added in direct response to the specificity hack that you see here. The last thing we need is authors hacking in 256 selectors for the sake of specificity workarounds. – BoltClock Dec 09 '14 at 16:12
5

This is all explained in a article:

extreme-specificity

Mark
  • 6,335
  • 1
  • 29
  • 49