For the previous few months, I’ve been writing a number of entries on pseudo-selectors in CSS, like ::picker() or ::checkmark. And, within the course of, I observed I have a tendency to make use of the :open pseudo-selector loads in my examples — and in my work usually.
Borrowing phrases from the advantageous creator of the :open entry within the Almanac:
The CSS
:openpseudo-selector targets parts that help open and closed states — such because theandparts — and selects them of their open state.
So, given this:
particulars:open {
background: lightblue;
coloration: darkred;
}We anticipate that the
However what if we wish to choose the “closed” state as an alternative? That’s what we’ve 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 will 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 form of article…)
Some background
Talks surrounding :open began in Could 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 parts within the high layer (like popups):
Right this moment, the OpenUI WC equally resolved so as to add a :top-layer pseudo class that ought to apply to (at the very least) parts utilizing the Popup API that are at the moment within the high layer. The intention for the naming and conduct, although, was that this pseudo class also needs to be normal function. It ought to match any sort of factor within the high layer, together with modal , fullscreen parts, and ::backdrop pseudo parts.
This sparked discourse on whether or not the title of the pseudo-element focusing on the highest layer of any sort of factor (e.g., popups, pickers, and so forth.) ought to both be :open or :top-layer. I, for one, was thrilled when the CSSWG finally selected :open in August 2022. The title makes much more sense to me as a result of “open” assumes one thing within the high layer.
To :shut or :not(:open)?
Maintain on, although! In September that very same 12 months, Mason requested whether or not or not we must always have one thing like a :closed pseudo-class to accompany :open. That manner, we will match parts of their “closed” states simply as we will their “open” states. That makes a number of sense, t least on the floor. Tab Atkins chimed in:
I really like this definition, as I feel it captures an idea of “openness” that traces up with what most builders suppose “open” means. I additionally suppose it makes it comparatively easy for HTML to attach it to particular parts.
What do of us suppose?
Ought to we additionally speak about including the corresponding
:closedpseudo class? That might 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 we’ve a pseudo-class that targets parts of their :open state, absolutely it is sensible to have :closed to focus on parts 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 12 months:
I opened a brand new difficulty about
:closedas a result of this doesn’t have consensus but (#11039).
Wait, what occurred to consensus? It’s the identical query I raised on the high of this submit. In line with Luke Warlow:
Making
:closedmatch 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-closedas a result of it’s the inverse of:popover-open.
There is no such thing as a :closed… for now
Quick ahead yet one more month to November 2024. A consensus was made to begin out with simply :open and take away :closed in the meanwhile.
Dang. Nonetheless, in accordance with WHATWG and CSSWG, that call may change sooner or later. In actual fact, Bramus dropped a helpful notice 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 grasp?
Personally, I’m okay with :closed — and even utilizing :not(:open) — as far as it really works. In actual fact, I went forward swapped :closed for :not(:open) in my ::checkmark and ::picker() examples. That’s why they’re they manner they’re at the moment.
However! When you have 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 suppose in literal phrases than negated statements.
What do you suppose, although? Would you like having :closed or simply leaving it as :not(:open)?
When you’re like me and you like following discussions like this, you possibly can all the time head over to CSSWG drafts on GitHub to look at or take part within the enjoyable.
