What's new in CSS Selectors 4 | Hacker News Reader

What's new in CSS Selectors 4

grack.com

70 pointsmmastrac21 comments

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.

I'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/

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.

So 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)

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

Given how close CSS selector semantics are to things like XPath I wonder if they'll eventually converge to being equivalent.

I think that :has syntax is pretty horrific... the '!' syntax was much simpler to read, but I see the reasoning behind making it function-like as the subject of the selector then remains looking like it did before.

Where exactly one uses nth-selector other than to style first/last and even/odd items?

We are using nth-selector to style icon for nav items, which IMO is a wrong way of styling nav items.

There are some good CSS <del>selector</del> properties like position sticky but not available in most browsers :(

You can use nth-child/nth-last-child for much more than table even/odd styling. It can be used to style children based on the number of siblings they have, build grids out of list items, or style grid interval tick marks on a timeline off the top of my head.

A cleaner way of targeting elements with a specific number of children exists using EQCSS for Element Queries:

   @element '.sidebar' and (max-children: 5) {

     .widget h3 {
       font-size: 125%;
     }

   }

Check out the min-children/max-children examples on: http://elementqueries.com/test.html

> There are some good CSS selector like position sticky but not available in most browsers

position:sticky isn't a selector.

    <selector> {<property>: <value>}

:shame:

It's not a selector, it's a property. It exists, but support is not good. It's been behind a flag in Chrome for over well two years. http://caniuse.com/#search=sticky

Earlier post from the same blog, showing usage for building image grids:

http://grack.com/blog/2015/01/09/abusing-css3-selectors/

I find it useful for creating pseudo random unit tests, targeting specific elements on the page.

Nice additions coming, but I can't wait for browser support so I write my CSS in Element Queries to reach things CSS can't normally reach:

- http://staticresource.com/calendar-demo.html

What, we can't get a pseudo-selector for tooltips so we can style those?

Tooltips aren't a web standard or even part of the shadow DOM, so styling them is a stretch.

I can hover over an element with its title attrib set, and one pops up on every browser.

It's just a nice thing most browsers do. It's a part of those browsers, not the web. Most browsers have tabs these days, but tabs aren't part of the web either.

Last I heard, if there are two different implementations of a feature, the W3C considers it to be a de facto standard.

Nor are there any useful distinctions between "browsers" and "the web".

What I suggest is that CSS 4 have the necessary functionality to specify styling of tooltips. It's not that bizarre of an idea. You could set the font, for instance, or colors, or borders. Likely once it becomes a psuedo-element, you could do even fancier things with it.

It's a no-brainer.

If :has is not fast, then it's not very useful, otherwise it's great for, say, selecting previous siblings (which is impossible at the moment).

:has sounds like it can lead to a maintenance mess and makes styles being tied to specific mark-up. I can imagine how easy it will be to accidentally add stuff that some broad rule will assimilate, or remove styling because you add an innocent element to the block. It locks down stuff the same way too much nesting does.

Reply on news.ycombinator.com