- From: Benjamin Poulain <benjamin@webkit.org>
- Date: Tue, 21 Jul 2015 15:05:13 -0700
- To: Brian Kardell <bkardell@gmail.com>, fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>, Philippe Le Hégaret <plh@w3.org>
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 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
Received on Tuesday, 21 July 2015 22:06:02 UTC