Re: [csswg-drafts] More intuitive names for selector performance profiles

> but meanwhile I think it's good that :has() in JS is not held back

Wait, isnt't it? I've been pretty sure it *is* held back by implementors (at least, according to the [MDN's compatibility table](https://developer.mozilla.org/en-US/docs/Web/CSS/:has#Browser_compatibility)). I suppose it might be because browser vendors aren't very interestedthe in implementing it because the same result in JS can already be achieved with existing tools (including Selector API — for `.something:has(.somethingElse)`, either by selecting all `.something .somethingElse` entries and than looking up the chain of ancestors or by selecting all `.something` elements and then filter them with `element.querySelector('.somethingElse')`, which jQuery seems to do). The current proposal has been there since 2014, but the best vendor response I've seen so far was "Under consideration with Priority: low" [from Microsoft](https://developer.microsoft.com/en-us/microsoft-edge/platform/status/cssrelationalpseudoclasshas/) (please correct me if I missed something).

I didn't mean that the _functionality_ of `:has()` selector in JS is completely useless itself, I just supposed that implementors aren't very interested in implementing it _because_ the limited use of this feature doesn't seem to be worth the effort to them. But I hope this could change if this limitation goes.

I like the idea of separate `:has-following-siblings()` and `:has-children()` selectors (or something similar). Probably it would be a good starting point to add this functionality to CSS.

-- 
GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1694#issuecomment-320872227 using your GitHub account

Received on Tuesday, 8 August 2017 07:18:30 UTC