Ought to We Even Have :closed? | CSS-Methods

For the previous few months, I’ve been writing a variety of entries on pseudo-selectors in CSS, like ::picker() or ::checkmark. And, within the course of, I seen I have a tendency to make use of the :open pseudo-selector lots in my examples — and in my work usually.

Borrowing phrases from the high-quality writer of the :open entry within the Almanac:

The CSS :open pseudo-selector targets components that assist open and closed states — such because the <particulars> and <choose> components — and selects them of their open state.

So, given this:

particulars:open {
  background: lightblue;
  shade: darkred;
}

We anticipate that the <particulars> ingredient will get a light-weight blue background and darkish pink textual content when it’s in an open state (in every single place however Safari on the time I’m penning this):

However what if we wish to choose the “closed” state as a substitute? That’s what now we have the:closed pseudo-class for, proper? It’s supposed to match a component’s closed state. I say, supposed as a result of it’s not specced but.

However does it must be specced in any respect? I solely ask as a result of we are able to nonetheless goal a component’s closed state with out it utilizing :not():

/* When particulars is _not_ open, however closed */
particulars:not(:open) {
  /* ... */
}

So, once more: do we actually want a :closed pseudo-class? The reply might shock you! (Simply kidding, this isn’t that kind of article…)

Some background

Talks surrounding :open began in Might 2022 when Mason Freed raised the difficulty of including :open (which was additionally thought-about being named :top-layer on the time) to focus on components within the prime layer (like popups):

At the moment, the OpenUI WC equally resolved so as to add a :top-layer pseudo class that ought to apply to (a minimum of) components utilizing the Popup API that are at the moment within the prime layer. The intention for the naming and conduct, although, was that this pseudo class must also be common objective. It ought to match any kind of ingredient within the prime layer, together with modal <dialog>, fullscreen components, and ::backdrop pseudo components.

This sparked discourse on whether or not the identify of the pseudo-element focusing on the highest layer of any kind of ingredient (e.g., popups, pickers, and so forth.) ought to both be :open or :top-layer. I, for one, was thrilled when the CSSWG ultimately selected :open in August 2022. The identify makes much more sense to me as a result of “open” assumes one thing within the prime layer.

To :shut or :not(:open)?

Maintain on, although! In September that very same yr, Mason requested whether or not or not we must always have one thing like a :closed pseudo-class to accompany :open. That means, we are able to match components of their “closed” states simply as we are able to their “open” states. That makes a variety of sense, t least on the floor. Tab Atkins chimed in:

I like this definition, as I feel it captures an idea of “openness” that traces up with what most builders assume “open” means. I additionally assume it makes it comparatively simple for HTML to attach it to particular components.

What do of us assume?

Ought to we additionally discuss including the corresponding :closed pseudo class? That will keep away from the issue that :not(:open) can match something, together with issues that don’t open or shut.

And guess what? Everybody appeared to agree. Why? As a result of it made sense on the time. I imply, since now we have a pseudo-class that targets components of their :open state, certainly it is sensible to have :closed to focus on components of their closed states, proper? Proper??

No. There’s truly a problem with that line of reasoning. Joey Arhar made a remark about it in October that very same yr:

I opened a brand new concern about :closed as a result of this doesn’t have consensus but (#11039).

Wait, what occurred to consensus? It’s the identical query I raised on the prime of this submit. In accordance with Luke Warlow:

Making :closed match issues that may by no means be open feels odd. And would basically make it :not(:open) through which case will we even want :closed? Like we don’t have a :popover-closed as a result of it’s the inverse of :popover-open.

There is no such thing as a :closed… for now

Quick ahead yet another month to November 2024. A consensus was made to start out out with simply :open and take away :closed in the meanwhile.

Dang. Nonetheless, based on WHATWG and CSSWG, that call may change sooner or later. Actually, Bramus dropped a helpful be aware in there only a month earlier than WHATWG made the choice:

Simply dropping this as an FYI: :read-only is outlined as :not(:read-write), and that shipped.

Which do you discover simpler to know?

Personally, I’m okay with :closed — and even utilizing :not(:open) — as far as it really works. Actually, I went forward swapped :closed for :not(:open) in my  ::checkmark and ::picker() examples. That’s why they’re they means they’re immediately.

However! Should you had been to ask me which one comes simpler to me on a typical day, I feel I’d say :closed. It’s simpler for to assume in literal phrases than negated statements.

What do you assume, although? Would you like having :closed or simply leaving it as :not(:open)?

Should you’re like me and you like following discussions like this, you’ll be able to at all times head over to CSSWG drafts on GitHub to observe or take part within the enjoyable.