Re: [selectors4] Specificity in base 256

On Thu, Aug 16, 2012 at 3:33 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Selectors specificity is calculated from three integers a, b and c and:
>
>> Concatenating the three numbers a-b-c (in a number system with a
>> large base) gives the specificity.
>
>
> My understanding is that "a large base" means one larger than any of a, b
> and c. In other words, the final specificity is not a single number but a
> tuple of 3 integers, compared in lexicographic order.
>
> Apparently, "a large base" is 256 in Gecko and WebKit:
>
> http://stackoverflow.com/questions/2809024/points-in-css-specificity/11934505#11934505
> http://news.ycombinator.com/item?id=4388649
>
> I’m not sure about other engines.

Opera too, I believe.

> Should the spec be made more precise on this point? Is it deliberately vague
> to allow this kind of behavior? (Using a single int is probably more
> efficient.)
>
> In my opinion, the behavior in Gecko and WebKit is incorrect but the
> approximation is good enough. I don’t know if this makes a difference in any
> real stylesheet (ie. not made for the purpose of experimenting with
> specificity.)
>
> To keep a single integer but be more correct (IMO), implementation could
> also clamp b and c to a maximum like 255 rather than letting them overflow.

The spec is completely clear.  The behavior exhibited by the browsers
is a bug.  However, it's also a completely unimportant bug that no one
will ever run into unless they are specifically trying to test for it,
or they're doing something *really* messed up with automated selector
generation. I would be completely fine with declaring any bugs filed
against WebKit about this as WONTFIX, because doing it "right" will
likely slow down selector matching (by making specificity sorting
slower) by an appreciable amount.

~TJ

Received on Thursday, 16 August 2012 14:51:15 UTC