Re: [selectors4] Features to Defer

On 7/21/15 5:31 PM, Brian Kardell wrote:
> On Tue, Jul 21, 2015 at 8:29 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Jul 21, 2015 at 2:43 PM, Brian Kardell <bkardell@gmail.com> wrote:
>>> Why postpone :has again?  it's already been booted from like 1999 to
>>> selectors 3, then 4, then "only for static profile" and now we want to
>>> move it to 5?  why?  in the static profile this isn't hard and jQuery
>>> has had it since, I think day one.
>>
>> Because we still aren't seeing implementations snapping at it.  We're
>> prepping for CR; we don't want things in CR that nobody's planning on
>> implementing.
>
> fair enough.  I'd feel better if any implementer could really share a
> good reason about why this is complex though, it seems like an easy
> win, I must be missing something.

For WebKit and Blink, the implementation would be easy as long as we 
don't care about scalability. In the old SelectorChecker, we would just 
have a tree walker testing the selector passed as argument.

The parser changes may be bigger than the matching code :)

Getting it into the JIT compiler would be significantly harder. The JIT 
only knows how to traverse trees upward.
:has() is the kind of selector that greatly benefits from the JIT.

If you are familiar with C++ and interested in this, I can help you get 
started on the SelectorChecker version for WebKit. The same code could 
trivially be ported to Blink. (the JIT version for WebKit can come later 
when the feature is no longer at risk)

Benjamin

Received on Wednesday, 22 July 2015 00:55:43 UTC