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 14:27:29 +0200
To: "Simon Sapin" <simon.sapin@kozea.fr>, "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <op.wi6p73h6tmo5g6@localhost.localdomain>
On Thu, 16 Aug 2012 16:50:28 +0200, Tab Atkins Jr. <jackalmage@gmail.com>  

> 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

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 12:28:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:02 UTC