Add the :open and :closed pseudo-selectors #10126

josepharhar · 2024-02-07T22:07:51Z

These pseudo-selectors are defined in CSS here: https://drafts.csswg.org/selectors-4/#open-state

These match on details, dialog, and select elements since they can be in an open or closed state. When they are open they match :open, and then they are closed they match :closed.

At least two implementers are interested (and none opposed):
Tests are written and can be reviewed and commented upon at:
- Implement :open and :closed pseudo classes web-platform-tests/wpt#44454
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/324293874
- Gecko: …
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=280637
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/semantics-other.html ( diff )

These pseudo-selectors are defined in CSS here: https://drafts.csswg.org/selectors-4/#open-state

josepharhar · 2024-02-07T22:09:19Z

source

+     </li>
+
+     <li><p>If <var>element</var> is a <code>select</code> element and <var>element</var> is being
+     rendered as a button with a popup and the popup is open, then return true.</p></li>


I know this is very vague, but the select element as specced never mentions that it can be an in-page listbox or a button with a popup. I figure that it makes sense to match neither :open or :closed when it is being rendered as an in-page listbox with no popup, but in any case we need some way of saying that the popup is open.

Doesn't the rendering section have something to reuse for this? If we're going to depend on rendering I feel like we'd want to at least link to a shared concept.

Oh yeah it is defined in rendering! https://html.spec.whatwg.org/multipage/rendering.html#list-box

However, I don't think the definition reflects browsers because it says that having the multiple attribute means that it renders a list box, but in iOS safari and android chrome having the multiple attribute renders as a drop-down box.

Maybe I could fix that separately?

For now I've referenced the "drop-down box" definition from rendering

josepharhar · 2024-02-07T22:09:36Z

@nt1m maybe you're interested in this?

annevk

Thanks for tackling this!

source

annevk · 2024-02-08T08:42:00Z

source

+      <p>If <var>element</var> is a <code>details</code> or <code>dialog</code> element:</p>
+
+      <ol>
+       <li><p>Return true if <var>element</var> has the <code data-x="attr-dialog-open">open</code>


You cannot point to a specific open attribute if it's about two distinct ones. Using data-x="" should suffice.

I separated them and referred to specific open attributes. Look good?

annevk · 2024-02-08T08:43:06Z

source

+     </li>
+
+     <li><p>If <var>element</var> is a <code>select</code> element and <var>element</var> is being
+     rendered as a button with a popup and the popup is open, then return true.</p></li>


Doesn't the rendering section have something to reuse for this? If we're going to depend on rendering I feel like we'd want to at least link to a shared concept.

annevk · 2024-02-08T08:43:31Z

source

+   <dt><dfn selector><code data-x="selector-closed">:closed</code></dfn></dt>
+   <dd>
+    <p>The <code data-x="selector-closed">:closed</code> <span>pseudo-class</span> must match any
+    element that <span>matches the closed selector</span>.<p>


Can be inlined.

I combined the paragraphs, does it look good?

source

domenic · 2024-02-09T09:12:26Z

These match on details, dialog, and select elements since they can be in an open or closed state.

Has it been discussed whether they should match other pickers besides select, like color pickers, date pickers, etc.? Basically all the things that showPicker() triggers.

josepharhar · 2024-02-09T20:15:01Z

Has it been discussed whether they should match other pickers besides select, like color pickers, date pickers, etc.? Basically all the things that showPicker() triggers.

That sounds great! I just used it on the elements that the css spec listed, but I don't see any reason why we shouldn't support <input> as well.

I think this might get nuanced even more than <select> since some browsers have popups for date/time input types and others don't. How should I proceed?

annevk · 2024-02-10T08:17:26Z

I wonder if we can turn "If no such UI applies to element" into a rendering concept and branch :open/:closed on that. That would also allow you to detect picker support. This should not introduce a new fingerprinting vector as it will be 1:1 with the user agent.

cc @nt1m @pxlcoder @lukewarlow

lukewarlow · 2024-02-10T14:20:21Z

As far as I understand the reason showPicker() doesn't return a success boolean was because browsers explicitly didn't want to "leak" the information about whether they show a picker on these elements, I think it was for forwards compatability so they'd be free to add them in future without people relying too much on them existing or not in a given UA.

I personally think it would be great if we could apply these to those elements and support the feature detection for showPicker().

lukewarlow · 2024-02-18T21:14:46Z

source

+     <li><p>A <code>dialog</code> element which has the <code data-x="attr-dialog-open">open</code>
+     attribute.</p></li>
+
+     <li><p>A <code>select</code> element which is a <span>drop-down box</span> whose drop-down box


This might be irelevant for the HTML spec but Firefox for Android renders a multiple or size select as a list box but also opens a modal when clicked, should that match :open?

Also Chromium for Android renders selects as a conventional drop down style but opens a modal not a drop down, should that match :open?

Just trying to clarify because the "drop-down box" terminology is ambiguous as first glance.

Yeah if it opens as a modal when clicked then I don't see why it shouldn't match :open

annevk · 2024-02-19T23:10:04Z

If it was decided that showPicker() shouldn't reveal that information we should not make :open and :closed applicable to those elements until we decide otherwise. It seems reasonable to explore further as a follow-up though.

josepharhar · 2024-02-20T14:35:38Z

As far as I understand the reason showPicker() doesn't return a success boolean was because browsers explicitly didn't want to "leak" the information about whether they show a picker on these elements

I'd be interested to hear more about this, is there a conversation you can point to?

lukewarlow · 2024-02-20T15:23:29Z

I'd be interested to hear more about this, is there a conversation you can point to?

Absolutely, so there's an open issue regarding lack of feature detection for showPicker() here and that links to a TAG design review comment here

It seems the lack of support detection was the hang up that lead to an unsatisfied resolution in TAG.

My earlier remark that "browsers" didn't want to leak might be a mischaracterisation upon further reading. But the sentiment is the same, it was concluded that it was an undesirable compat trade off.

josepharhar · 2024-02-20T17:09:52Z

Absolutely, so there's an open issue regarding lack of feature detection for showPicker() #7790 and that links to a TAG design review comment w3ctag/design-reviews#688 (comment)

Thanks! @domenic do you think these issues still apply with this pseudo class?

domenic · 2024-02-22T07:17:13Z

Thanks! @domenic do you think these issues still apply with this pseudo class?

It depends exactly how they're defined. Consider a case like <input type=password> where browser A shows a picker and browser B does not show a picker. If we define this as matching :closed in browser B, then the issues do not occur: the web developer cannot write code that works differently in browser A vs. B. Whereas if we say that neither :open nor :closed match in browser B, then the web developer can easily write code that works differently in the two browsers, e.g. they might give only the correct styling to browser A because they put the correct styling in #my-input:closed { ... }.

Similarly, if we go with the "neither :open or :closed matches no-picker controls" model, then browser B adding picker support in one release would potentially cause new styles to apply, which is a compat risk for browser B.

That said, I don't feel that the interop and compat issues with revealing the picker-UI-or-not status of a control are blocking. I think they're reason to be cautious, but if all the implementers in the room are willing to eat those interop and future-compat costs, then from a HTML editor perspective, I have no objection.

annevk · 2024-03-04T11:54:01Z

I suppose that essentially argues for making :closed match all elements, or at least all elements that might have a picker UI. @whatwg/css does that seem reasonable?

lukewarlow · 2024-05-28T19:00:34Z

Following up on this another place where we'd potentially like to do something that exposes picker UI existence is with invokers. If we were to add showPicker actions to invokers then it would seem logical (though I'm no expert so this might be wrong) that it exposes an aria-expanded state based on the inputs picker state?

If aria-expanded should be added it would be unfortunate if we couldn't because of this compat risk (though admittedly it's not currently detectable in code so maybe it's fine?)

lukewarlow · 2024-07-25T01:08:03Z

Something I've just thought of. Would it be worth exposing this on datalist elements? They're kind of input pickers but also they're a separate element so idk if input:open matching necessarily makes sense for a datalist?

josepharhar · 2024-08-26T19:56:55Z

Something I've just thought of. Would it be worth exposing this on datalist elements? They're kind of input pickers but also they're a separate element so idk if input:open matching necessarily makes sense for a datalist?

I feel like input:open makes more sense than datalist:open since we are planning on doing select:open rather than select::picker(select):open

lukewarlow · 2024-09-30T21:14:15Z

WebKit bug at https://bugs.webkit.org/show_bug.cgi?id=280637

josepharhar · 2024-10-08T22:15:02Z

I suppose that essentially argues for making :closed match all elements, or at least all elements that might have a picker UI. @whatwg/css does that seem reasonable?

I think that making :closed match "all elements" makes sense based on domenic's explanation for compat. I added another line for input elements and said that they should always match either open or closed. I also made all select elements match either open or closed regardless of whether they have list-box rendering or not.

lukewarlow · 2024-10-10T11:46:50Z

Is one possibility to ship :open and not :closed initially? Making :closed match things that can never be open feels odd.
And would essentially make it :not(:open) in which case do we even need :closed? Like we don't have a :popover-closed because it's the inverse of :popover-open.

annevk

I agree with Luke that starting out with just :open is better, but we should run that by the CSS WG.

annevk · 2024-10-10T11:57:59Z

source

+     <li><p>A <code>select</code> element which is a <span>drop-down box</span> whose drop-down box
+     is open.</p></li>
+
+     <li><p>An <code>input</code> element which supports a picker popup and whose picker popup is
+     open.</p></li>


It would be good to have some shared language (ideally in terms of <dfn>) with showPicker() here. I.e., #10126 (comment), but I no longer think it would make picker support detectable if the condition is "supports a picker and picker is open".

bramus · 2024-10-11T14:01:13Z

Is one possibility to ship :open and not :closed initially? Making :closed match things that can never be open feels odd. And would essentially make it :not(:open) in which case do we even need :closed? Like we don't have a :popover-closed because it's the inverse of :popover-open.

Just dropping this as an FYI: :read-only is defined as :not(:read-write), and that shipped – https://html.spec.whatwg.org/multipage/semantics-other.html#selector-read-only.

Add the :open and :closed pseudo-selectors

842c489

These pseudo-selectors are defined in CSS here: https://drafts.csswg.org/selectors-4/#open-state

josepharhar commented Feb 7, 2024

View reviewed changes

annevk reviewed Feb 8, 2024

View reviewed changes

use drop-down box

8b1e0da

josepharhar mentioned this pull request Feb 9, 2024

[selectors] Add :open or :top-layer pseudo class w3c/csswg-drafts#7319

Closed

rewrite matching algorithm

77fe1ec

lukewarlow reviewed Feb 18, 2024

View reviewed changes

Merge branch 'main' into openclosedpseudo

8ec3467

make :closed match all elements

c23f7f9

This was referenced Oct 8, 2024

:open and :closed pseudo-classes WebKit/standards-positions#413

Open

:open and :closed pseudo-classes mozilla/standards-positions#1085

Open

annevk reviewed Oct 10, 2024

View reviewed changes

josepharhar mentioned this pull request Oct 15, 2024

[selectors-4] Should we have :open and :closed? w3c/csswg-drafts#11039

Open

annevk mentioned this pull request Nov 6, 2024

"Show the picker" steps never dismisses the picker upon node removal #10743

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add the :open and :closed pseudo-selectors #10126

Add the :open and :closed pseudo-selectors #10126

josepharhar commented Feb 7, 2024 •

edited

Loading

josepharhar Feb 7, 2024

annevk Feb 8, 2024

josepharhar Feb 9, 2024

josepharhar Feb 9, 2024

zcorpan Oct 10, 2024

josepharhar commented Feb 7, 2024

annevk left a comment

annevk Feb 8, 2024

josepharhar Feb 9, 2024

annevk Feb 8, 2024

annevk Feb 8, 2024

josepharhar Feb 9, 2024

domenic commented Feb 9, 2024

josepharhar commented Feb 9, 2024

annevk commented Feb 10, 2024

lukewarlow commented Feb 10, 2024

lukewarlow Feb 18, 2024

josepharhar May 29, 2024

annevk commented Feb 19, 2024 •

edited

Loading

josepharhar commented Feb 20, 2024

lukewarlow commented Feb 20, 2024

josepharhar commented Feb 20, 2024

domenic commented Feb 22, 2024

annevk commented Mar 4, 2024

lukewarlow commented May 28, 2024

lukewarlow commented Jul 25, 2024

josepharhar commented Aug 26, 2024

lukewarlow commented Sep 30, 2024

josepharhar commented Oct 8, 2024

lukewarlow commented Oct 10, 2024

annevk left a comment

annevk Oct 10, 2024 •

edited

Loading

bramus commented Oct 11, 2024

Add the :open and :closed pseudo-selectors #10126

Are you sure you want to change the base?

Add the :open and :closed pseudo-selectors #10126

Conversation

josepharhar commented Feb 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josepharhar commented Feb 7, 2024

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Feb 9, 2024

josepharhar commented Feb 9, 2024

annevk commented Feb 10, 2024

lukewarlow commented Feb 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Feb 19, 2024 • edited Loading

josepharhar commented Feb 20, 2024

lukewarlow commented Feb 20, 2024

josepharhar commented Feb 20, 2024

domenic commented Feb 22, 2024

annevk commented Mar 4, 2024

lukewarlow commented May 28, 2024

lukewarlow commented Jul 25, 2024

josepharhar commented Aug 26, 2024

lukewarlow commented Sep 30, 2024

josepharhar commented Oct 8, 2024

lukewarlow commented Oct 10, 2024

annevk left a comment

Choose a reason for hiding this comment

annevk Oct 10, 2024 • edited Loading

Choose a reason for hiding this comment

bramus commented Oct 11, 2024

josepharhar commented Feb 7, 2024 •

edited

Loading

annevk commented Feb 19, 2024 •

edited

Loading

annevk Oct 10, 2024 •

edited

Loading