W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [selectors4] Features to Defer

From: Benjamin Poulain <benjamin@webkit.org>
Date: Wed, 22 Jul 2015 01:05:59 -0700
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org
Message-ID: <55AF4EE7.5070206@webkit.org>
On 7/22/15 12:41 AM, Daniel Glazman wrote:
> On 22/07/2015 02:54, Benjamin Poulain wrote:
>
>> 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.
>
> (w/o my co-chairman's hat and with my former editorship/authorship
>   of Selectors L3)
>
> That's exactly, precisely, the reason that already blocked some
> extensions of Selectors some oh... fourteen to fifteen years ago.
> "the code only knows how to traverse the tree upward". I find it
> extremely disturbing for our WG reputation to discover only now it
> must be postponed because implementors - who pushed the feature forward
> in the draft - won't/can't implement it for that same reason.

Regarding the tree traversal, I did not mean to imply this was 
preventing an implementation. JITing tree descent is not exactly rocket 
science :)

I am willing to help any dev who wants to add an experimental 
implementation of :has() in WebKit.

> So I have the feeling this is not only a technical decision. This is
> also a decision about managing this document and not holding a feature
> forever. Maybe we should stop adding to this document things that have,
> from the start, a too high probability of not making it, despite of
> potentially immense usefulness to our users. Selectors are the very
> first thing Web authors learn and manipulate; I bet a cookie they will
> eventually become the only selecting mechanism in Web Standards, just
> like XSL-FOs are out of the game on the Web in favor of CSS. We must be
> extra-careful with that spec, because it's one the cornerstones of CSS.
> The draft is too much an idea sink instead of being a list of things
> that are in hyper-vast majority on path to implementation.
>
> As said earlier in this thread, :has() has a long history. A long
> history of never making it, unfortunately. The subject selector was
> probably far easier to implement, including in a JIT compiler, ahem,
> and I feel, as a WG member, totally ridiculous to postpone :has() again
> for the n-th time in more than fifteen years.

Can you please give some context? I only joined this group last year. 
This is the first time I hear someone taking the subject selector seriously.

Was there any discussion about how the matching is supposed to work 
efficiently?

> Maybe we need to make a choice now about either keeping in L4 but only
> in static profile or dropping the feature. And if the former means
> giving priority to this feature during next weeks and confcalls, let's
> do that instead of deferring to a L5. The WG has a face-to-face meeting
> in a month from now; this is the right moment to make a final decision
> and that gives us some time to do cleanup. Giving Web authors false
> expectations over 15 years seems to me counter-productive for the
> Working Group. That way of doing, with a deadline, seems to me better
> than moving immediately to CR with no clear decision on :has().
>
> </Daniel>
>
>
Received on Wednesday, 22 July 2015 08:06:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC