skip to content

In CSS, there are compound selectors and also complex selectors, and I never remember which is which. Do you need to learn the difference? Probably not. But I’m tired of looking it up.

From the specification:

A compound selector is a sequence of simple selectors that are not separated by a combinator, and represents a set of simultaneous conditions on a single element.

Simple selectors are all the little bits – a class, a tag, an ID, etc. Those can be combined in various ways.

These are compound selectors:

img#hero {}
a:focus {}
.only.with.all.of.these.classes {}

A complex selector is a sequence of one or more compound selectors separated by combinators.

Those compound selectors weren’t complex enough for you? Try combining them! These selectors are complex:

#hero img {}
a:focus > .icon {}
.only.with ~ .all.of ~ .these.siblings {}

Simple selectors describe element properties, that can get merged together into compound selectors describing entire elements, and then joined into complex selectors that put those elements in the context of relationships. And we can string all that together into selector lists, targeting multiple elements based on a variety of properties and relationships. It’s a big world out there, kids. A big, declarative, cascading world.

Now you I know. Now you I can forget again, and know exactly where to look.

WebMentions

Nicholas Stimpson

on twitter.com

It would be easier if each version of the Selectors spec didn't change the terminology. Hopefully we can stick with that of Selectors Level 4.

fantasai

on twitter.com

Compound selectors are like compound words. That is why we call them compound selectors. Complex selectors describe relationships among multiple elements, which is what makes them complex.

fantasai

on twitter.com

Look up “complex (adj)” in the dictionary as an exercise, maybe that’ll help it stick. :) The “two or more interrelatedness parts” bit really evokes the “two or more interrelated elements” aspect.

Jhey 🔨🐻✨

on twitter.com

Discussing this the other day and perhaps a sneak peek of something I'll mention in my talk but a different type of compound combinator would be rad for stateful stuff 😎 Like... form:has([id="one"]:valid & [id="terms"]:checked) Where those items might be nested in a form 🤔

Jhey 🔨🐻✨

on twitter.com

Yes? 😅 Can we chain a :has like that? I know, we can't do something like: form:has(form-group:has(:valid) + form-group:has(:valid)) But, if form:has():has():has() is gonna work then technically, I could be tweaking some of my demos and slides 😅

Jhey 🔨🐻✨

on twitter.com

Although, I'm definitely not rejigging the "Big ones". Way too much work at this late stage when they're not styled yet ha 😅 We'll see!

Jhey 🔨🐻✨

on twitter.com

Thinking about it, it's because I wanted to do something particularly for turn-based things with the :has(:has) to flip a custom property 🤔✨

Mia (not her best work)

on twitter.com

Spec says they can't be nested like that, but I don't see anything about chaining. At least not in the current ED. But if there are reasons to disallow chained :has(), I would expect those same reasons to apply to a new syntax that has the same meaning.

Jhey 🔨🐻✨

on twitter.com

I'll take another look at my more "flamboyant" demos on the plane and see if I can rejig the mechanics 🤔 But, to be fair, this is another great thing about trying to push this stuff. Learning the ins and outs of the spec as I go along 😅