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

Re: [selectors4] Specificity in base 256

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 17 Aug 2012 09:40:40 -0700
Message-ID: <CAAWBYDAGUQfu3UcLwZzVggOvK9=k4v_ut2nLj_aGEYfMhZe7Gw@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Simon Sapin <simon.sapin@kozea.fr>, "www-style@w3.org" <www-style@w3.org>
On Fri, Aug 17, 2012 at 6:32 AM, Aryeh Gregor <ayg@aryeh.name> wrote:
> On Thu, Aug 16, 2012 at 5:50 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.
>
> However, this means that we know there are not two interoperable
> implementations of this part of CSS 4 Selectors, so it shouldn't be
> able to progress to PR.  Since browsers all behave the same, it makes
> the most sense to just spec what browsers do, and add a test.  I don't
> see any justification for keeping the spec as-is except if you think
> that the spec should be theoretically pure rather than matching
> implementations.

This is reasonable.  Simon's suggested algorithm (2), loosened up a
bit, would work.  Basically, just keep the existing requirement that
an id is more specific than infinite classes, but put in a MAY that
allows browsers to stop counting specificity in a particular group
past an implementation-defined limit (in other words, if they are
recording specificity in a single int, clamp each group to the limit).

I'd patch WebKit to match that.

fantasai, what do you think about making this change to Selectors 4?

~TJ
Received on Friday, 17 August 2012 16:41:28 GMT

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