[css-ui] Pseudo-element for select's UA popover

[josepharhar]

Customizable <select> will have a popover element inside the UA shadowroot for the picker. We need a pseudo-element to target this element, and it needs a name and some supported capabilities.

We recently discussed removing the capability for the author to provide their own popover element as a <datalist> in OpenUI here, which means that this pseudo-element will only be for the UA shadowroot popover rather than possibly also being for an author-provided element.

For the name, the chromium prototype implementation currently has ::select-fallback-datalist (this name would need improvement), but I imagine based on this issue that some people would like for it to be called ::picker(select).

One capability which I know will be needed is popover / top layer animations. In order to support this, we need this pseudo-element to support the :popover-open pseudo-class and some other things so that the following code works when in base appearance mode:

select::select-fallback-datalist {
  transition: display 1s allow-discrete, overlay 1s allow-discrete, opacity 1s;
  opacity: 0;
}

select::select-fallback-datalist:popover-open {
  opacity: 1;
}
@starting-style {
  select::select-fallback-datalist:popover-open {
    opacity: 0;
  } 
}

[nt1m]

I think the existing :open / :closed should be used. The UA using a popover seems like an implementation detail to me.

:open::picker(select) 
:closed::picker(select) 

[josepharhar]

Thanks for the feedback! :open seems to work perfectly for animations

[nt1m]

(Fwiw, I do think we should not be exposing :popover-open to the picker pseudo-element, it should just be rejected at parse time)

[josepharhar]

(Fwiw, I do think we should not be exposing :popover-open to the picker pseudo-element, it should just be rejected at parse time)

As long as :popover-open can be replaced with select:open in the example code in the issue description and the animations work, then I am ok with this. I guess it might be harder for authors to know to switch it around when going from popover animations to select popover animations, but at least they have the capability.

[nt1m]

It definitely should not reduce any customization/animation capabilities, the suggestion is purely stylistic so people don't have to remember that popover is used internally and so that there's only one way to do things :)

[josepharhar]

Proposed resolution: ::picker(select) is a part-like pseudo-element which applies to select elements which are in base appearance mode. It maps to the popover element inside the select's UA shadowroot.

[nt1m]

Is it the "fallback" popover only?

[josepharhar]

Is it the "fallback" popover only?

It won't map to the author-provided popover because I am removing that entire concept/capability: openui/open-ui#1082

So yes, it is the "fallback" popover only. Does this answer your question?

[nt1m]

Ah great, more simplification!

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Pseudo-element for select's UA popover, and agreed to the following:

• RESOLVED: ::picker(select) is a part-like pseudo-element which applies to select elements which are in base appearance mode. It maps to the popover element inside the select's UA shadowroot.

The full IRC log of that discussion

<emilio> jarhar: we need a pseudo to provide things like animations when open / closed
<emilio> ... we removed the capability for the author list so it should only map to the popover element within the select's UA shadow root
<ntim> sounds good
<emilio> ... proposed resolution is `::picker(select)`
<emilio> annevk: one thing to talk about is whether we should resolve on the pseudo-classes
<masonf> q+
<emilio> jarhar: ntim pointed out that we can use `:open` / `:closed`
<emilio> ... which works for my use case
<astearns> ack masonf
<emilio> ... but we define it as a part-time pseudo-element which may have implication
<una> q+
<emilio> dbaron: I need to double-check but I think part-like pseudo-elements would allow matching `:popover-open`
<emilio> masonf: `:open` should apply to the `<select>` itself, and I think this should be a part-like pseudo-element so I think `:popover-open` would apply
<emilio> q+
<astearns> ack una
<emilio> ... would be weird to forbid it
<emilio> una: if we can just reuse open / popover-open that'd be the most straight-forward, would be just the same for everything
<astearns> ack emilio
<dbaron> ScribeNick: dbaron
<dbaron> emilio: I think if we make it a part and it's well defined when it opens/closes (as it should be), then the only pseudo classes that wouldn't apply would be tree-structural ones.
<dbaron> emilio: I think that's fine.
<dbaron> emilio: I think we should do that for everything we can.
<ntim> q+
<dbaron> ScribeNick: emilio
<masonf> q+
<emilio> annevk: making it a part-like makes sense, but not sure exposing that it is a popover makes sense, feels more like an implementation detail
<emilio> ... not great that there are two ways of doing the same thing
<astearns> ack ntim
<emilio> ntim: +1 to annevk
<jarhar> using popover is an "implementation detail", but its going to be explicitly defined to be a popover
<emilio> ... I don't think there should be any burden on the developer to remember that it's a popover
<astearns> q+
<emilio> ... the provision can be done through an allowlist, there are already some parsing rules for pseudo-classes after pseudo-elements
<emilio> ... so it's straight-forward to add a restriction here IMO
<emilio> q+
<astearns> ack masonf
<emilio> masonf: I agree we shouldn't burden the developer with the knowledge that it's a popover, developers can use `:open`
<emilio> ... but it is a popover
<emilio> ... and that gives you extra capabilities
<emilio> ... so I don't think it's wrong to expose that it is in fact a popover
<emilio> ... if you don't know that it's a popover that's fine and you can use `:open` / `:close`
<emilio> annevk: what's the additional power?
<emilio> masonf: the transition stuff for the top layer
<jarhar> q?
<emilio> annevk: why can't you use `:open`?
<emilio> masonf: you need to know that it's in the top layer
<emilio> annevk: but that has nothing to do with the pseudo-class
<emilio> una: you can do the same with either selector
<emilio> masonf: yeah didn't mean specifically about the pseudo-class, just the fact it's a popover
<una> q?
<emilio> annevk: I think ntim meant mostly about the selector matching but maybe more?
<emilio> ntim: yeah I just mean that you shouldn't need to know it's a popover for the pseudo-class
<emilio> masonf: If it's only about the pseudo-class I think I'm ok backing down
<emilio> annevk: yeah I think it's mostly about it
<emilio> ... another question about the part-like thing
<astearns> ack emilio
<emilio> ... does that mean that custom state matches? Or I guess never matches but it's not an error
<ntim> q+
<annevk> emilio: we shouldn't ban :popover-open, if it's going to be a part-like pseudo-element
<annevk> emilio: I think that's better overall, even if it's redundant
<astearns> ack ntim
<emilio> ntim: I only thing technical priority is important
<emilio> ... very confusing when there's two ways to do the same thing
<masonf> q+
<emilio> ... the developer would wonder whether there's something different
<emilio> q+
<jarhar> q?
<astearns> q+ later
<emilio> ... the dev experience should be better
<astearns> ack astearns
<emilio> s/better/the priority
<emilio> annevk: we could make it part-like but just never match
<jarhar> i think that the dx is better if we allow :popover-open because developers might try it, and it doesn't work, and they'll never even try to use select:open because they don't know about it
<emilio> ... I think that'd still meet emilio's point
<emilio> ... but not create duplicate APIs
<emilio> ... the other thing with popover-open is really web-dev-facing API
<emilio> ... while <select> is sort-of built-in
<emilio> ... just like we're not exposing there is an internal shadow root attached
<una> q+
<emilio> ... we shouldn't expose the primitives it's built on
<emilio> masonf: there's a bit of a technical purity argument for making part-like pseudos do the same everywhere
<emilio> ... but also from a developer point of view is also weird reading about the base-select popup and realizing it's a popover
<emilio> ... and then `:popover-open` doesn't work
<emilio> astearns: should we resolve on the name and move popover-open matching to a different issue?
<emilio> annevk: fine for me
<astearns> ack emilio
<dbaron> ScribeNick: dbaron
<dbaron> emilio: we expose many redundant apis in CSS, it's not a bug
<dbaron> emilio: I don't buy the argument that it makes it more complex for developers.
<dbaron> emilio: If we want to hide that it's a real dom element, we shouldn't make it a part-like pseudo-element.
<dbaron> emilio: I think that would be unfortunate.
<dbaron> emilio: But you could apply that argument like we do for ::placeholder because it may not be an element.
<dbaron> emilio: The weird state where it's a part-like pseudo-element but doesn't match the pseudo-class is *more* confusing
<dbaron> ScribeNick: emilio
<emilio> annevk: the pseudo-class is defined to match elements with the popover attribute
<emilio> ... it ends up exposing the fact that it's an html element with a particular attribute etc
<astearns> ack una
<emilio> una: just wanted to ask, could we use `:open` for popovers?
<emilio> ... that'd normalize it, and it'd be a better developer experience
<emilio> annevk: yeah not sure why we ended up with this?
<emilio> masonf: yeah it was about what it applied to and was a bit of a can of work
<emilio> dbaron: there was an argument about how popover applies to elements to which popover can also apply
<emilio> una: so seems `:open` would be appropriate here
<dbaron> s/how popover/how :open/
<fantasai> I think our point is that we want form controls to act like they’re built into the language, not built out of author facilities in the language; and that their full functionality can be implemented without those author facilities.
<jarhar> Proposed resolution: ::picker(select) is a pseudo-element which applies to select elements which are in base appearance mode. It maps to the popover element inside the select's UA shadowroot.
<ntim> good point that `:popover-open::picker(select)` and `::picker(select):popover-open` mean different things
<emilio> astearns: I wasn't part of the open-ui discussion about how we ended up with the part like pseudos but there's some weirdness in the definition
<dbaron> s/can also apply/can also apply (attribute semantics versus element semantics)/
<emilio> annevk: I think the issue about part-like pseudos is mostly about popover-open matching
<emilio> ... because that reveals details about how the shadow dom is structured
<emilio> q+
<emilio> ack astearns
<emilio> ntim: also brought up on irc that `:popover-open::picker(select)` means something different than `::picker(select):popover-open`
<emilio> ... one means that the select is in a popover state and the other that the picker
<masonf> select:popover-open will never match, because the select isn't a popover
<emilio> ... is open
<emilio> ... I'd rather forbid the second bit
<dbaron> ScribeNick: dbaron
<dbaron> emilio: I just don't get the... to me :popover-open is not particularly different than allowing all the other things that part-like pseudos allow.
<dbaron> emilio: allowing inheritance reveals things about tree structure.
<dbaron> emilio: How we define part-like pseudos is just how parts work.
<astearns> ack emilio
<dbaron> emilio: It seems weird to forbid this one thing and not all the other things.
<keithamus> q+
<dbaron> emilio: though this one thing does expose that it's an html element
<dbaron> emilio: You could argue that maybe we couldn't match :popover-open across shadow roots, but authors wouldn't be happy about that.
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<dbaron> emilio: If :popover-open revealing that you're an html element is an issue... all the pseudo-classes that we allow after part have the same issue.
<dbaron> emilio: for example, :open only matches select, details, etc.
<dbaron> emilio: so it has the same issue
<dbaron> emilio: so to me the issue is part-like pseudo versus something with more restrictions
<dbaron> ScribeNick: emilio
<astearns> ack keithamus
<emilio> annevk: I think that means that the element on the other side shouldn't be one of those things just like it shouldn't be a `<fieldset>`
<emilio> ... because that matches `:enabled`
<masonf> q+
<emilio> keithamus: custom element authors don't have the same ability to have restrictions
<emilio> ... not sure why the browser would be different
<emilio> annevk: if you build a web component you can't provide custom pseudos
<emilio> emilio: you can use parts
<emilio> annevk: right but those are not built-in
<emilio> ntim: I think the equivalent would be custom state
<emilio> ack mfreed
<astearns> Proposed resolution: ::picker(select) is a part-like pseudo-element which applies to select elements which are in base appearance mode. It maps to the popover element inside the select's UA shadowroot.
<emilio> masonf: I wonder if we should move this to a different issue
<emilio> q+
<masonf> +1 to proposed resolution
<emilio> annevk: that's fine
<dbaron> s/move this to/resolve ond part-like and move question of matching :popover-open to/
<keithamus> +1
<emilio> astearns: can we resolve on `::picker(select)` as a part-like pseudo, with a different issue to whether popover-open applies or not?
<dandclark> +1
<emilio> annevk: sounds fine
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<dbaron> +1
<jarhar> RESOLVED: ::picker(select) is a part-like pseudo-element which applies to select elements which are in base appearance mode. It maps to the popover element inside the select's UA shadowroot.