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?

Received on Friday, 17 August 2012 16:41:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:35:14 UTC