Add the :open and :closed pseudo-selectors #10126
Conversation
These pseudo-selectors are defined in CSS here: https://drafts.csswg.org/selectors-4/#open-state
| </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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
For now I've referenced the "drop-down box" definition from rendering
|
@nt1m maybe you're interested in this? |
| <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> |
There was a problem hiding this comment.
You cannot point to a specific open attribute if it's about two distinct ones. Using data-x="" should suffice.
There was a problem hiding this comment.
I separated them and referred to specific open attributes. Look good?
| </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> |
There was a problem hiding this comment.
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.
| <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> |
There was a problem hiding this comment.
I combined the paragraphs, does it look good?
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 I think this might get nuanced even more than |
|
I wonder if we can turn "If no such UI applies to element" into a rendering concept and branch |
|
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(). |
| <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 |
There was a problem hiding this comment.
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.
|
If it was decided that |
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. |
Thanks! @domenic do you think these issues still apply with this pseudo class? |
It depends exactly how they're defined. Consider a case like Similarly, if we go with the "neither 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. |
|
I suppose that essentially argues for making |
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.
(See WHATWG Working Mode: Changes for more details.)
/semantics-other.html ( diff )