CSS4 Preview – Selectors

by dkd903 • 14 years ago

87 34 14 years ago

I like the $ syntax. It's powerful.

Can somebody explain the slash syntax in the example given?

    label:matches(:hover, :focus) /for/ input {

cleverjake• 14 years ago

"The example above highlights an INPUT element when its LABEL is focused or hovered-over; the association is made by the for attribute of the label. As you can probably tell, the id is implied by the LABEL element's for attribute."

eCa• 14 years ago

Consider the following html:

  <label for="first_checkbox">A label</label>
  <input type="checkbox" id="first_checkbox" />

  <label for="another_checkbox">Another label</label>
  <input type="checkbox" id="another_checkbox" />

And css:

  label:matches(:hover, :focus) /for/ input {
      margin: 30px;
  }

If the user then hovers the first label (for="first_checkbox") the input (id="first_checkbox") will get an annoying margin.

The syntax uses the id named in the for-attribute to connect with the element with the same id.

chrisbroadfoot2• 14 years ago

Right. I get it. Basically an infix notation. Seems inconsistent with the rest of CSS.

tlb• 14 years ago

It's easy to cook up a syntax for selecting parents. The hard part is implementing it efficiently. It requires browsers to scan more of the DOM tree when elements are changed. I expect it to be one of the (many) parts of CSS that are avoided by websites that want to render quickly.

snookca• 14 years ago

Exactly. And just because there's a draft specification, doesn't mean browsers will implement it.

masklinn7• 14 years ago

I'm not sure, CSS selectors are already matched left-to-right so you're not scanning more stuff, it's just that you're selecting an other level of your match tree.

    ul > li > p

    ul > $li > p

have the same matching complexity: the browser finds all p on the page, then checks if their parent is a li, then checks if that parent is a ul. The difference (which may or may not require significant work) is that before the check acted as a filter on the originally matched object, whereas now there's a transform/translation.

garindra• 14 years ago

What about LESS-style nested selectors? I've been using it in my projects and it improves my workflow tremendously. I'd be thrilled if it's finally integrated into the CSS specification.

jacobr• 14 years ago

Might be harder to pull off wrt backwards compatibility.

bps44844• 14 years ago

how so? Sass and Less seem to be able to pull it off.

geuis• 14 years ago

Instead of $el > el syntax, wouldn't a simple version be better?

* el < el

I've run into many situations over the years where being able to select parent elements based on a child would have come in handy. I think it would be a lot simpler to just use < for direct parents, as > is used for direct children.

saurik3• 14 years ago

A) Using < would cause parsing problems when the stylesheet is embedded in an enclosing HTML document. B) If you think about it, the selector is still functioning the same: you are simply moving which node is being "targeted"; I would therefore hope that you could also do "$el + el" to select nodes that came before other nodes. (edit: Reading the linked update to the specification, it seems like the people who wrote it did not see that this would be a useful, beautiful, and arguably important generalization; sigh.)

bps44844• 14 years ago

could you elaborate on A? What's the problem of using "<" in an enclosing html document that wouldn't also be a problem for ">", which already exists?

bps44844• 14 years ago

I thought the same thing when I read about "$" and thought they should use "<" as you suggest. I don't like that the last element in a chain of css isn't the target.

wavephorm• 14 years ago

Given the number of years it'll take for CSS3 to be used reliably, this information isn't very useful.

batista• 14 years ago

Given that you can target modern browsers like Chrome and Safari and Firefox, and either fuck IE and older versions (e.g for an inhouse app) or just have then not support some fancy features, it's VERY useful.

You don't have to have all of CSS3 implemented everywhere to be useful. Same for CSS4.

md224• 14 years ago

This article might be a bit out of date... it appears the $ selector has been changed to an exclamation point:

http://dev.w3.org/csswg/selectors4/#subject

yaix6• 14 years ago

Why only select an element based on its children? How about

el /if/ el > .someclass:hover { some:style; }

Style an element "el" if some other element exists or event occurs.

yaix6• 14 years ago

wtf? Why do I get downvoted? Could the downvoter explain please.

Again, insteat of being able to just select a parent on the existence of a child, why not be able to select any element on the existence of another element? Change the background of a body > div if there is only one child in a list body > ul > li:only-child for example.

body > div /if/ body > ul > li:only-child { background:green; }

Or replace /if/ with :: or $ or whatever.

masklinn7• 14 years ago

I'm not sure you understand what /op/ does.

It's a reference indirection going through an IDREF type:

* It finds whatever elements are before the operator

* It gets the value of the operator's attribute (or type IDREF), ~ storing it in $ID

* it combines the selector after it with the root being extended with `[id=$ID]`

`/if/` would get the value of the attribute `if` and try to find an element with that value as its id.

yaix6• 14 years ago

There is one good point in the comments: "MATH! We need math! 50% -5px It’s stupid having to do things like this in JS."

Completely agree! It should be possible to do this.

And please: vertical-align:center for any block element. Or is that in CSS3 and I am not aware of it?

Twisol• 14 years ago

You can use calc (https://developer.mozilla.org/en/CSS/calc), but it isn't well supported.

masklinn7• 14 years ago

I'm not sure how I feel about CSS selectors closing in on XPath 1.0 in terms of power, except with far, far higher levels of syntactic complexity.

CSS4 Preview – Selectors

Related Stories