Re: [selectors4] Specificity in base 256

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 UTC