- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Aug 2024 15:36:11 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <emilio> jarhar: we need a pseudo to provide things like animations when open / closed<br> <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<br> <ntim> sounds good<br> <emilio> ... proposed resolution is `::picker(select)`<br> <emilio> annevk: one thing to talk about is whether we should resolve on the pseudo-classes<br> <masonf> q+<br> <emilio> jarhar: ntim pointed out that we can use `:open` / `:closed`<br> <emilio> ... which works for my use case<br> <astearns> ack masonf<br> <emilio> ... but we define it as a part-time pseudo-element which may have implication<br> <una> q+<br> <emilio> dbaron: I need to double-check but I think part-like pseudo-elements would allow matching `:popover-open`<br> <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<br> <emilio> q+<br> <astearns> ack una<br> <emilio> ... would be weird to forbid it<br> <emilio> una: if we can just reuse open / popover-open that'd be the most straight-forward, would be just the same for everything<br> <astearns> ack emilio<br> <dbaron> ScribeNick: dbaron<br> <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.<br> <dbaron> emilio: I think that's fine.<br> <dbaron> emilio: I think we should do that for everything we can.<br> <ntim> q+<br> <dbaron> ScribeNick: emilio<br> <masonf> q+<br> <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<br> <emilio> ... not great that there are two ways of doing the same thing<br> <astearns> ack ntim<br> <emilio> ntim: +1 to annevk<br> <jarhar> using popover is an "implementation detail", but its going to be explicitly defined to be a popover<br> <emilio> ... I don't think there should be any burden on the developer to remember that it's a popover<br> <astearns> q+<br> <emilio> ... the provision can be done through an allowlist, there are already some parsing rules for pseudo-classes after pseudo-elements<br> <emilio> ... so it's straight-forward to add a restriction here IMO<br> <emilio> q+<br> <astearns> ack masonf<br> <emilio> masonf: I agree we shouldn't burden the developer with the knowledge that it's a popover, developers can use `:open`<br> <emilio> ... but it is a popover<br> <emilio> ... and that gives you extra capabilities<br> <emilio> ... so I don't think it's wrong to expose that it is in fact a popover<br> <emilio> ... if you don't know that it's a popover that's fine and you can use `:open` / `:close`<br> <emilio> annevk: what's the additional power?<br> <emilio> masonf: the transition stuff for the top layer<br> <jarhar> q?<br> <emilio> annevk: why can't you use `:open`?<br> <emilio> masonf: you need to know that it's in the top layer<br> <emilio> annevk: but that has nothing to do with the pseudo-class<br> <emilio> una: you can do the same with either selector<br> <emilio> masonf: yeah didn't mean specifically about the pseudo-class, just the fact it's a popover<br> <una> q?<br> <emilio> annevk: I think ntim meant mostly about the selector matching but maybe more?<br> <emilio> ntim: yeah I just mean that you shouldn't need to know it's a popover for the pseudo-class<br> <emilio> masonf: If it's only about the pseudo-class I think I'm ok backing down<br> <emilio> annevk: yeah I think it's mostly about it<br> <emilio> ... another question about the part-like thing<br> <astearns> ack emilio<br> <emilio> ... does that mean that custom state matches? Or I guess never matches but it's not an error<br> <ntim> q+<br> <annevk> emilio: we shouldn't ban :popover-open, if it's going to be a part-like pseudo-element<br> <annevk> emilio: I think that's better overall, even if it's redundant<br> <astearns> ack ntim<br> <emilio> ntim: I only thing technical priority is important<br> <emilio> ... very confusing when there's two ways to do the same thing<br> <masonf> q+<br> <emilio> ... the developer would wonder whether there's something different<br> <emilio> q+<br> <jarhar> q?<br> <astearns> q+ later<br> <emilio> ... the dev experience should be better<br> <astearns> ack astearns<br> <emilio> s/better/the priority<br> <emilio> annevk: we could make it part-like but just never match<br> <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<br> <emilio> ... I think that'd still meet emilio's point<br> <emilio> ... but not create duplicate APIs<br> <emilio> ... the other thing with popover-open is really web-dev-facing API<br> <emilio> ... while <select> is sort-of built-in<br> <emilio> ... just like we're not exposing there is an internal shadow root attached<br> <una> q+<br> <emilio> ... we shouldn't expose the primitives it's built on<br> <emilio> masonf: there's a bit of a technical purity argument for making part-like pseudos do the same everywhere<br> <emilio> ... but also from a developer point of view is also weird reading about the base-select popup and realizing it's a popover<br> <emilio> ... and then `:popover-open` doesn't work<br> <emilio> astearns: should we resolve on the name and move popover-open matching to a different issue?<br> <emilio> annevk: fine for me<br> <astearns> ack emilio<br> <dbaron> ScribeNick: dbaron<br> <dbaron> emilio: we expose many redundant apis in CSS, it's not a bug<br> <dbaron> emilio: I don't buy the argument that it makes it more complex for developers.<br> <dbaron> emilio: If we want to hide that it's a real dom element, we shouldn't make it a part-like pseudo-element.<br> <dbaron> emilio: I think that would be unfortunate.<br> <dbaron> emilio: But you could apply that argument like we do for ::placeholder because it may not be an element.<br> <dbaron> emilio: The weird state where it's a part-like pseudo-element but doesn't match the pseudo-class is *more* confusing<br> <dbaron> ScribeNick: emilio<br> <emilio> annevk: the pseudo-class is defined to match elements with the popover attribute<br> <emilio> ... it ends up exposing the fact that it's an html element with a particular attribute etc<br> <astearns> ack una<br> <emilio> una: just wanted to ask, could we use `:open` for popovers?<br> <emilio> ... that'd normalize it, and it'd be a better developer experience<br> <emilio> annevk: yeah not sure why we ended up with this?<br> <emilio> masonf: yeah it was about what it applied to and was a bit of a can of work<br> <emilio> dbaron: there was an argument about how popover applies to elements to which popover can also apply<br> <emilio> una: so seems `:open` would be appropriate here<br> <dbaron> s/how popover/how :open/<br> <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.<br> <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.<br> <ntim> good point that `:popover-open::picker(select)` and `::picker(select):popover-open` mean different things<br> <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<br> <dbaron> s/can also apply/can also apply (attribute semantics versus element semantics)/<br> <emilio> annevk: I think the issue about part-like pseudos is mostly about popover-open matching<br> <emilio> ... because that reveals details about how the shadow dom is structured<br> <emilio> q+<br> <emilio> ack astearns<br> <emilio> ntim: also brought up on irc that `:popover-open::picker(select)` means something different than `::picker(select):popover-open`<br> <emilio> ... one means that the select is in a popover state and the other that the picker<br> <masonf> select:popover-open will never match, because the select isn't a popover<br> <emilio> ... is open<br> <emilio> ... I'd rather forbid the second bit<br> <dbaron> ScribeNick: dbaron<br> <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.<br> <dbaron> emilio: allowing inheritance reveals things about tree structure.<br> <dbaron> emilio: How we define part-like pseudos is just how parts work.<br> <astearns> ack emilio<br> <dbaron> emilio: It seems weird to forbid this one thing and not all the other things.<br> <keithamus> q+<br> <dbaron> emilio: though this one thing does expose that it's an html element<br> <dbaron> emilio: You could argue that maybe we couldn't match :popover-open across shadow roots, but authors wouldn't be happy about that.<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <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.<br> <dbaron> emilio: for example, :open only matches select, details, etc.<br> <dbaron> emilio: so it has the same issue<br> <dbaron> emilio: so to me the issue is part-like pseudo versus something with more restrictions<br> <dbaron> ScribeNick: emilio<br> <astearns> ack keithamus<br> <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>`<br> <emilio> ... because that matches `:enabled`<br> <masonf> q+<br> <emilio> keithamus: custom element authors don't have the same ability to have restrictions<br> <emilio> ... not sure why the browser would be different<br> <emilio> annevk: if you build a web component you can't provide custom pseudos<br> <emilio> emilio: you can use parts<br> <emilio> annevk: right but those are not built-in<br> <emilio> ntim: I think the equivalent would be custom state<br> <emilio> ack mfreed<br> <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.<br> <emilio> masonf: I wonder if we should move this to a different issue<br> <emilio> q+<br> <masonf> +1 to proposed resolution<br> <emilio> annevk: that's fine<br> <dbaron> s/move this to/resolve ond part-like and move question of matching :popover-open to/<br> <keithamus> +1<br> <emilio> astearns: can we resolve on `::picker(select)` as a part-like pseudo, with a different issue to whether popover-open applies or not?<br> <dandclark> +1<br> <emilio> annevk: sounds fine<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <dbaron> +1<br> <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.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10758#issuecomment-2305056084 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 August 2024 15:36:12 UTC