W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: [selectors4] Specificity in base 256

From: Leif Arne Storset <lstorset@opera.com>
Date: Fri, 17 Aug 2012 15:02:14 +0200
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.wi6rt0u1tmo5g6@localhost.localdomain>
On Fri, 17 Aug 2012 14:27:29 +0200, Leif Arne Storset <lstorset@opera.com>  
wrote:

> On Thu, 16 Aug 2012 16:50:28 +0200, Tab Atkins Jr.  
> <jackalmage@gmail.com> wrote:
>
>> 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.
>
> Actually, our base is 24 (see attachment). It's just that we truncate  
> the count before concatenating. :j

Should be base 25, obviously. Not that it matters much.

> Having such a low limit could be considered a bug, but I think  
> dependending on specificities of class counts that high is rare/messed  
> up enough to be irrelevant, much like the Gecko/WebKit issue. Both ours  
> and other engines' assumptions could be proven wrong, of course.

-- 
Leif Arne Storset
Layout Developer, Opera Software
Oslo, Norway
Received on Friday, 17 August 2012 13:02:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT