[selectors4] Features to Defer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[selectors4] Features to Defer

fantasai
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

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Brian Kardell
On Tue, Jul 21, 2015 at 4:30 PM, fantasai <[hidden email]> 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.

--
Brian Kardell :: @briankardell :: hitchjs.com

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Benjamin Poulain-3
On 7/21/15 2:43 PM, Brian Kardell wrote:

> On Tue, Jul 21, 2015 at 4:30 PM, fantasai <[hidden email]> 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 would personally prefer if we investigated how to restrict :has() to
run in a reasonable time, then enable it for styling.

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.

Benjamin


Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Previous-sibling selector (was: Features to Defer)

Marat Tanalin | tanalin.com
In reply to this post by fantasai
21.07.2015, 23:33, "fantasai" <[hidden email]>:
>  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:


What about ability to select previous sibling? (Like existing `+` combinator, but for previous sibling.)

When it has been proposed to add previous-sibling combinator [1], Tab said that the feature is already covered by the more universal subject indicator [2] in conjunction with `:matches()` or by `:has()`.

Then subject indicator has been dropped [3] in favor of `:has()`.

But `:has()` was/became available only in fast/static profile (i.e. JS-only).

Then Tab said that the WG is probably going to make `:has()` available in complete/dynamic profile with some restrictions (probably limitation of using only simple selectors inside `:has()`) [4].

Now the Selectors spec is close to be finalized, and `:has()` is at risk to be postponed.

So what about previous-sibling selector (exactly previous-sibling selector unlike complicated universal things like `:has()`)?

Thanks.

[1] https://lists.w3.org/Archives/Public/www-style/2012Jan/1245.html
[2] https://lists.w3.org/Archives/Public/www-style/2012Jan/1248.html
[3] https://lists.w3.org/Archives/Public/www-style/2014Feb/0617.html
[4] https://lists.w3.org/Archives/Public/www-style/2015Feb/0306.html

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Brian Kardell
In reply to this post by Benjamin Poulain-3
On Tue, Jul 21, 2015 at 6:05 PM, Benjamin Poulain <[hidden email]> wrote:

> On 7/21/15 2:43 PM, Brian Kardell wrote:
>
>> On Tue, Jul 21, 2015 at 4:30 PM, fantasai <[hidden email]>
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Tab Atkins Jr.
In reply to this post by Brian Kardell
On Tue, Jul 21, 2015 at 2:43 PM, Brian Kardell <[hidden email]> 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.

On Tue, Jul 21, 2015 at 3:05 PM, Benjamin Poulain <[hidden email]> wrote:
> 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.
>
> 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.

I hear the opposite - I've heard from a lot of devs that are happy
about :has() (even tho they're sad it's not usable in stylesheets).

> I would personally prefer if we investigated how to restrict :has() to run
> in a reasonable time, then enable it for styling.

Yes, more research in this vein would be great.  It doesn't mean we
shouldn't do the general, slow :has() in the static profile still,
tho.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Brian Kardell
On Tue, Jul 21, 2015 at 8:29 PM, Tab Atkins Jr. <[hidden email]> wrote:
> On Tue, Jul 21, 2015 at 2:43 PM, Brian Kardell <[hidden email]> 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.



--
Brian Kardell :: @briankardell :: hitchjs.com

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Benjamin Poulain-3
On 7/21/15 5:31 PM, Brian Kardell wrote:

> On Tue, Jul 21, 2015 at 8:29 PM, Tab Atkins Jr. <[hidden email]> wrote:
>> On Tue, Jul 21, 2015 at 2:43 PM, Brian Kardell <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Pontus Horn af Rantzien
In reply to this post by fantasai
On Tue, 21 Jul 2015 at 22:33 fantasai <[hidden email]> 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:

What's the latest word on :nth-[last-]match()? Is that looking to make it to CR?

Pontus Horn af Rantzien
Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Previous-sibling selector (was: Features to Defer)

Tab Atkins Jr.
In reply to this post by Marat Tanalin | tanalin.com
On Tue, Jul 21, 2015 at 3:20 PM, Marat Tanalin <[hidden email]> wrote:

> 21.07.2015, 23:33, "fantasai" <[hidden email]>:
>>  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:
>
> What about ability to select previous sibling? (Like existing `+` combinator, but for previous sibling.)
>
> When it has been proposed to add previous-sibling combinator [1], Tab said that the feature is already covered by the more universal subject indicator [2] in conjunction with `:matches()` or by `:has()`.
>
> Then subject indicator has been dropped [3] in favor of `:has()`.
>
> But `:has()` was/became available only in fast/static profile (i.e. JS-only).
>
> Then Tab said that the WG is probably going to make `:has()` available in complete/dynamic profile with some restrictions (probably limitation of using only simple selectors inside `:has()`) [4].
>
> Now the Selectors spec is close to be finalized, and `:has()` is at risk to be postponed.

"Postponed" means "put into the Selectors 5 ED, so Selectors 4 can go
to CR".  We're just taking the subset of Selectors 4 that is ready for
CR, chopping it out, and upping the level on the rest.  It does not
materially change its status.

> So what about previous-sibling selector (exactly previous-sibling selector unlike complicated universal things like `:has()`)?

We have only had a few discussions on doing limited-function versions
of :has().  Previous-sibling (and parent) is on the table there, don't
worry.  Whether we still do it as a limited :has() grammar, or a more
specialized pseudo-class, is up in the air at the moment.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Boris Zbarsky
In reply to this post by Brian Kardell
On 7/21/15 8:31 PM, Brian Kardell wrote:
> I'd feel better if any implementer could really share a
> good reason about why this is complex though

Just because it's a new codepath to add to parsing and selector
matching, no?  It may not be particularly complex, but it's probably a
few days of work at least and may not be a top priority for implementors...

-Boris

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Sebastian Zartner-3
On 22 July 2015 at 04:08, Boris Zbarsky <[hidden email]> wrote:
> On 7/21/15 8:31 PM, Brian Kardell wrote:
>>
>> I'd feel better if any implementer could really share a
>> good reason about why this is complex though
>
>
> Just because it's a new codepath to add to parsing and selector matching,
> no?  It may not be particularly complex, but it's probably a few days of
> work at least and may not be a top priority for implementors...

If it's just "a few days of work", I wonder why the priority of
implementors lies somewhere else. From the discussions over many years
it should be clear that there is a strong desire from authors for this
feature.

Sebastian

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

fantasai
In reply to this post by Brian Kardell
On 07/21/2015 05:43 PM, Brian Kardell 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 there are still open discussions on it. If it was 100% settled,
we'd keep it in. The list we're proposing to keep is stuff that just
needs cleanup / minor issues fixed to go to CR. Basically, we are
housekeeping: dust off the finished things and put them in the shop
window while we keep working on the unfinished stuff in the back.

~fantasai

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Daniel Glazman
In reply to this post by Benjamin Poulain-3
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.

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.

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>


Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Benjamin Poulain-3
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>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Boris Zbarsky
In reply to this post by Sebastian Zartner-3
On 7/22/15 2:36 AM, Sebastian Zartner wrote:
> If it's just "a few days of work"

To be clear, a few days work for someone already familiar with the
selector-matching bits of the engine.  All of whom are occupied doing
other things.

> I wonder why the priority of
> implementors lies somewhere else.

Because other things (e.g. acute performance problems on real-life
websites) are more important.  What those things are probably varies by
implementor.

> From the discussions over many years
> it should be clear that there is a strong desire from authors for this
> feature.

There are strong desires from authors for many other things as well,
unfortunately...

-Boris

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Daniel Glazman
In reply to this post by Benjamin Poulain-3
On 22/07/2015 10:05, Benjamin Poulain wrote:

> 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.

Sure. The subject selector is something I introduced myself back in 1998
in a CSS-like language called STTS; STTS standing for Simple Tree
Transformation Sheets, I guess you understand easily what it was about.
At that time, the selector was called the "selected element selector"
and its first iteration was a :selected() functional pseudo-class (no
flames please :-) ) specifying, in a selector, the subject of the
selector. I eventually moved from that pseudo to a very easy to
understand ! descriptor and called it the subject selector.
Trivial examples:

  div > p  matches all p directly inside a div
  !div > p matches all div directly containing a p

In terms of implementation, it changes nothing to the "match selectors
from the deepest condition to the upmost one", but it potentially
defers the application of the selector to a subsequent climb in the
tree. I understand it impacts the implementation and requires some
changes. I implemented it in a batch processor handling STTS.

In terms of usage, this was far less powerful than :has(). But it was
also far simpler to use and read, and most certainly easier to
implement. From a Web author's perspective, it covered most of the
cases needed _at that time_. I still think it would be a superb
addition to Selectors, probably highly welcomed by our users.

Is that enough context?

</Daniel>

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Daniel Glazman
In reply to this post by Boris Zbarsky
On 22/07/2015 10:24, Boris Zbarsky wrote:

>> I wonder why the priority of
>> implementors lies somewhere else.
>
> Because other things (e.g. acute performance problems on real-life
> websites) are more important.  What those things are probably varies by
> implementor.

Right; each vendor follows its own market strategy with workforces that
aren't unlimited and there is nothing wrong with that. It can slow
things down on our standardization end, but that's life.

</Daniel>


Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Tab Atkins Jr.
In reply to this post by Pontus Horn af Rantzien
On Tue, Jul 21, 2015 at 5:48 PM, Pontus Horn af Rantzien
<[hidden email]> wrote:
> On Tue, 21 Jul 2015 at 22:33 fantasai <[hidden email]> 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:
>
> What's the latest word on :nth-[last-]match()? Is that looking to make it to
> CR?

We dropped that a long time ago, in favor of folding the functionality
into :nth-child().  And that is on the list as something to review for
inclusion in 4 vs 5. ^_^

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [selectors4] Features to Defer

Manuel Rego Casasnovas
In reply to this post by fantasai

On 21/07/15 22:30, fantasai wrote:
>   ? Column combinator
>       Want to double-check satisfaction with syntax, impl interest
>   ? :nth-column() pseudo-class
>       Biased to at-risk

Regarding this, I think that a column and row selector would be handy
for CSS Grid Layout. I don't know if it was discussed previously or not,
but it seems an interesting use case.

Just one example, imagine that you have a grid showing a random number
of elements (images, texts, whatever) and the grid have several rows and
columns, maybe you want to use a different background for items in
odd/even rows.

Anyway IMHO it seems a clear case to be deferred to level 5.

My 2 cents,
  Rego

12