For the previous few months, I’ve been writing plenty 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 so much in my examples — and in my work normally.
Borrowing phrases from the superb creator of the :open entry within the Almanac:
The CSS
:openpseudo-selector targets components that assist open and closed states — such because theandcomponents — and selects them of their open state.
So, given this:
particulars:open {
background: lightblue;
shade: darkred;
}We anticipate that the
However what if we wish to choose the “closed” state as a substitute? 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 could shock you! (Simply kidding, this isn’t that form of article…)
Some background
Talks surrounding :open began in Might 2022 when Mason Freed raised the difficulty of including :open (which was additionally thought of being named :top-layer on the time) to focus on components within the prime layer (like popups):
At present, the OpenUI WC equally resolved so as to add a :top-layer pseudo class that ought to apply to (not less than) components utilizing the Popup API that are presently within the prime layer. The intention for the naming and habits, although, was that this pseudo class also needs to be basic goal. It ought to match any sort of ingredient within the prime layer, together with modal , fullscreen components, and ::backdrop pseudo components.
This sparked discourse on whether or not the title of the pseudo-element concentrating on the highest layer of any sort of ingredient (e.g., popups, pickers, and so on.) ought to both be :open or :top-layer. I, for one, was thrilled when the CSSWG ultimately selected :open in August 2022. The title 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 12 months, Mason requested whether or not or not we must always have one thing like a :closed pseudo-class to accompany :open. That method, we will match components of their “closed” states simply as we will their “open” states. That makes plenty of sense, t least on the floor. Tab Atkins chimed in:
I like this definition, as I believe it captures an idea of “openness” that strains up with what most builders suppose “open” means. I additionally suppose it makes it comparatively simple for HTML to attach it to particular components.
What do people suppose?
Ought to we additionally speak about including the corresponding
:closedpseudo 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 we’ve a pseudo-class that targets components of their :open state, absolutely it is smart to have :closed to focus on components of their closed states, proper? Proper??
No. There’s really a difficulty with that line of reasoning. Joey Arhar made a remark about it in October that very same 12 months:
I opened a brand new concern 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 prime of this publish. Based on Luke Warlow:
Making
:closedmatch issues that may by no means be open feels odd. And would basically make it:not(:open)by 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 isn’t any :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 might change sooner or later. In actual fact, 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 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 method they’re in the present day.
However! In case you have been to ask me which one comes simpler to me on a typical day, I believe I might say :closed. It’s simpler for me to suppose in literal phrases than negated statements.
What do you suppose, although? Would you favor having :closed or simply leaving it as :not(:open)?
In case 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.
