6 ms·
I acknowledge that it must be tough working on the CSS standard, and it's a job that I'm glad I don't have. But understanding and using CSS is hard enough witho
by DougWebb 12y ago
I acknowledge that it must be tough working on the CSS standard, and it's a job that I'm glad I don't have. But understanding and using CSS is hard enough without examples like this:
This opens up a great deal of new ways to match
content. For instance, a developer can match all
paragraphs that contain nothing but images:
// Match a paragraph that does not have anything that is not an image
p:not(:has(:not(img))):not(:empty)
You don't start introducing :has with a convoluted multi-negative example like that. You save that for after the reader understands what :has does, to demonstrate how it lets you do really complex expressions that you couldn't do before. Or maybe you don't bother with that at all, since it's probably a rare case, and the much more common case that you should emphasize is that :has lets you style an element based on the children it contains, which CSS doesn't let you do today.
And what does this mean?
Caveat: at this time the :has selector is not considered fast, which means that it may not be available for use in stylesheets.
Where else is a CSS selector useful? In particular, where else is the most interesting part of CSS Selectors 4 going to be useful? Don't tell me Javascript code, because I can already do this stuff in Javascript code, and more, without having to worry about browser support for a new CSS standard.
- mmastrac 12y agoI'm the author of the post linked here, but not the author of the spec. My goal was to introduce the new features -- obviously there was a bit of a "deep end" problem talking about :has and I need to do a bit more work on that part of the post. The distinction between "fast" and "complete" selectors is explained in the spec doc: http://dev.w3.org/csswg/selectors-4/ http://dev.w3.org/csswg/selectors-4/ Obviously I can't read the minds of the spec writers, but I imagine they don't know what the performance implications of :has() is right now and they don't want to commit to something that kills browser performance once it's out there in the wild.
- andybak 12y agoSo maybe wait until there's an implementation before deciding whether it's a good thing to have in the spec? (I don't necessarily mean "a vendor-specific implementation in a released browser" - but someone should be coding prototypes of this stuff. Adobe did it for some of their new additions - clearly marked as experimental in special builds of Chromium)
- gsnedders 12y agoThe general attitude is that things get in the spec once there is rough consensus they should be implemented, but can be dropped if they turn out to be unworkable with implementation experience.