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

Re: [selectors4] Features to Defer

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 21 Jul 2015 20:27:52 -0400
Message-ID: <CADC=+jetSy3hw-ixK3bJGFAeE0-SPfDbuTkV6ZR7Jh-2jyKkMw@mail.gmail.com>
To: Benjamin Poulain <benjamin@webkit.org>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>, Philippe Le H├ęgaret <plh@w3.org>
On Tue, Jul 21, 2015 at 6:05 PM, Benjamin Poulain <benjamin@webkit.org> wrote:
> On 7/21/15 2:43 PM, Brian Kardell wrote:
>> On Tue, Jul 21, 2015 at 4:30 PM, fantasai <fantasai.lists@inkedblade.net>
>> wrote:
>>> Prompted by plh, Tab and I just went over the Selectors 4 spec,
>>> to figure out what's ready to polish up and send to CR and what
>>> looks like it should stay in WD. Here's a list of what we propose
>>> to keep and defer:
>>> Keep:
>>>    * Everything in Level 3, obviously
>>>    * case-insensitive attribute selectors
>>>    * :matches(), :not()
>>>    * :dir(), :lang()
>>>    * :any-link, :current, :past, :future
>>>    * CSS UI selectors, possibly other than :read-only / :read-write (see
>>> below)
>>>    * :user-error
>>> Defer to L5 or Need More Info to Decide
>>>    ? :has()
>>>        Propose to defer.
>>>    ? :focus-within
>>>        Will keep if there's impl interest
>>>    ? :drop and :drop()
>>>        No idea, need info on impl status / interop
>>>    ? :read-only and :read-write
>>>        Vaguely recall someone wanting to drop this...
>>>    ? :placeholder-shown
>>>        Need to check impl status
>>>    ? :blank
>>>        Need to check impl status, would prefer a new name
>>>        (that doesn't evoke empty input fields)
>>>    ? :nth-child( An+B of <selector> )
>>>        Want to double-check satisfaction with syntax, impl interest
>>>    ? >> descendant selector
>>>        Bias towards dropping, want to check with implementers
>>>    ? Column combinator
>>>        Want to double-check satisfaction with syntax, impl interest
>>>    ? :nth-column() pseudo-class
>>>        Biased to at-risk
>>> Please send your thoughts on this list. :)
>>> ~fantasai
>> 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.
> The thing is, the engine will not do better than jQuery. There is little
> value in adding something complicated when JavaScript can do just as good.
I'm not someone who would usually disagree with a comment like this,
extensible web and all that, I favor a JS solution to prove things out
etc --- that said, I'm not actually understanding how this is hard to
add support in qsa for. You've got the parser and the treewalkers and
everything right there, once sizzle has set up its basic approach, the
selector definition is all of 2 lines of code.    I just find it kind
of silly that I have to get all of sizzle instead of using qsa which
is there in part because jquery (among others) proved it out in JS and
we have data for, which in turn included :has because it was in the
current proposal at the time (and that was so long ago). Is it really
actually hard?  Can you explain why?  I just want to understand why
we're interested in reversing/delaying this after so many years and
finally getting here at least.

> I would personally prefer if we investigated how to restrict :has() to run
> in a reasonable time, then enable it for styling.
I would prefer this too, but unbounded it is damn hard.  On
realistic/common size trees though it doesn't actually seem that hard
- hitchjs does it in real time in some reasonable cases, for example.

> Every time I discuss this subject with developers, they are not interested
> in :has() as it is today. They wanted similar capabilities for styling. In
> my humble opinion, that is what we should aim for.

Everyone wants this for CSS, like - everyone.  I'm something of a
realist though - if the options are "here's a useful feature and we'll
try to do more eventually but it's really really hard" vs "you get
nothing until we have both parts and we don't have the bandwidth, will
or ideas on the other part for now" - I'd just rather not hold my
breath.  Some value is measurably better than no value.

> Benjamin

Brian Kardell :: @briankardell :: hitchjs.com
Received on Wednesday, 22 July 2015 00:28:21 UTC

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