- From: Brian Kardell <bkardell@gmail.com>
- Date: Tue, 21 Jul 2015 20:27:52 -0400
- 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