- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 25 Aug 2024 14:03:07 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= OpenUI-WHATWG/HTML-CSSWG meeting ================================ CSS UI ------ - 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 (Issue #10758: Pseudo-element for select's UA popover) - A new issue will be opened to discuss having ::picker(select) match :popover-open. Form Controls ------------- - The group discussed the different proposals to resolve issue #10440 (Styling form control pickers). - There was some momentum toward fantasai's proposed text: https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166 however there were still concerns about the second point in the proposal and having one vs. two opt-ins. - Discussion will return to github to further debate the second point. Additionally, there was a request of Google to provide more details on their vision for the redesign. ===== FULL MEETING MINUTES ====== Agenda: https://github.com/whatwg/html/issues/10568 Present: Adam Argyle Joey Arhar David Baron Keith Cirkel Daniel Clark Emilio Cobos Álvarez Elika Etemad Chris Harrelson Mason Freed Una Kravets Tim Nguyen Alan Stearns Anne van Kesteren Scribe: emilio Scribe's scribe: dbaron OpenUI-WHATWG/HTML-CSSWG meeting ++++++++++++++++++++++++++++++++ CSS UI ====== Pseudo-element for select's UA popover -------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/10758 jarhar: We need a pseudo to provide things like animations when open / closed jarhar: We removed the capability for the author list so it should only map to the popover element within the select's UA shadow root jarhar: Proposed resolution is `::picker(select)` <ntim> sounds good annevk: One thing to talk about is whether we should resolve on the pseudo-classes jarhar: ntim pointed out that we can use `:open` / `:closed` jarhar: which works for my use case jarhar: but we define it as a part-time pseudo-element which may have implication dbaron: I need to double-check but I think part-like pseudo-elements would allow matching `:popover-open` 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 masonf: would be weird to forbid it una: If we can just reuse open / popover-open that'd be the most straight-forward, would be just the same for everything 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. emilio: I think that's fine. emilio: I think we should do that for everything we can. 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 annevk: not great that there are two ways of doing the same thing <jarhar> using popover is an "implementation detail", but its going to be explicitly defined to be a popover ntim: +1 to annevk ntim: I don't think there should be any burden on the developer to remember that it's a popover ntim: the provision can be done through an allowlist, there are already some parsing rules for pseudo-classes after pseudo-elements ntim: so it's straight-forward to add a restriction here IMO masonf: I agree we shouldn't burden the developer with the knowledge that it's a popover, developers can use `:open` masonf: but it is a popover masonf: and that gives you extra capabilities masonf: so I don't think it's wrong to expose that it is in fact a popover masonf: if you don't know that it's a popover that's fine and you can use `:open` / `:close` annevk: What's the additional power? masonf: The transition stuff for the top layer annevk: Why can't you use `:open`? masonf: You need to know that it's in the top layer annevk: But that has nothing to do with the pseudo-class una: You can do the same with either selector masonf: Yeah didn't mean specifically about the pseudo-class, just the fact it's a popover annevk: I think ntim meant mostly about the selector matching but maybe more? ntim: Yeah I just mean that you shouldn't need to know it's a popover for the pseudo-class masonf: If it's only about the pseudo-class I think I'm ok backing down annevk: Yeah I think it's mostly about it annevk: Another question about the part-like thing annevk: does that mean that custom state matches? Or I guess never matches but it's not an error emilio: We shouldn't ban :popover-open, if it's going to be a part-like pseudo-element emilio: I think that's better overall, even if it's redundant ntim: I only think technical priority is important ntim: very confusing when there's two ways to do the same thing ntim: the developer would wonder whether there's something different ntim: the dev experience should be the priority <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 annevk: We could make it part-like but just never match annevk: I think that'd still meet emilio's point annevk: but not create duplicate APIs annevk: the other thing with popover-open is really web-dev-facing API annevk: while <select> is sort-of built-in annevk: just like we're not exposing there is an internal shadow root attached annevk: we shouldn't expose the primitives it's built on masonf: There's a bit of a technical purity argument for making part-like pseudos do the same everywhere masonf: but also from a developer point of view is also weird reading about the base-select popup and realizing it's a popover masonf: and then `:popover-open` doesn't work astearns: Should we resolve on the name and move popover-open matching to a different issue? annevk: Fine for me emilio: We expose many redundant apis in CSS, it's not a bug emilio: I don't buy the argument that it makes it more complex for developers. emilio: If we want to hide that it's a real dom element, we shouldn't make it a part-like pseudo-element. emilio: I think that would be unfortunate. emilio: But you could apply that argument like we do for ::placeholder because it may not be an element. emilio: The weird state where it's a part-like pseudo-element but doesn't match the pseudo-class is *more* confusing annevk: The pseudo-class is defined to match elements with the popover attribute annevk: it ends up exposing the fact that it's an html element with a particular attribute etc una: Just wanted to ask, could we use `:open` for popovers? una: that'd normalize it, and it'd be a better developer experience annevk: Yeah not sure why we ended up with this? masonf: Yeah it was about what it applied to and was a bit of a can of worms dbaron: There was an argument about how :open applies to elements to which popover can also apply (attribute semantics versus element semantics) una: So seems `:open` would be appropriate here <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. <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. <ntim> good point that `:popover-open::picker(select)` and `::picker(select):popover-open` mean different things 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 annevk: I think the issue about part-like pseudos is mostly about popover-open matching annevk: because that reveals details about how the shadow dom is structured ntim: Also brought up on irc that `:popover-open::picker(select)` means something different than `::picker(select):popover-open` <masonf> select:popover-open will never match, because the select isn't a popover ntim: One means that the select is in a popover state and the other that the picker ntim: is open ntim: I'd rather forbid the second bit 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. emilio: Allowing inheritance reveals things about tree structure. emilio: How we define part-like pseudos is just how parts work. emilio: It seems weird to forbid this one thing and not all the other things. emilio: Though this one thing does expose that it's an html element emilio: You could argue that maybe we couldn't match :popover-open across shadow roots, but authors wouldn't be happy about that. 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. emilio: For example, :open only matches select, details, etc. emilio: so it has the same issue emilio: so to me the issue is part-like pseudo versus something with more restrictions 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>` annevk: because that matches `:enabled` keithamus: Custom element authors don't have the same ability to have restrictions keithamus not sure why the browser would be different annevk: If you build a web component you can't provide custom pseudos emilio: You can use parts annevk: Right but those are not built-in ntim: I think the equivalent would be custom state <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. masonf: I wonder if we should resolve on part-like and move question of matching :popover-open to a different issue <masonf> +1 to proposed resolution annevk: That's fine <keithamus> +1 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 annevk: Sounds fine <dbaron> +1 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. Form Controls ============= Styling form control pickers ---------------------------- github: https://github.com/w3c/csswg-drafts/issues/10440 jarhar: Last time we talked about appearance: base and base-select and applying it to `::picker()` jarhar: Looks like both me and fantasai proposed some text we can resolve on jarhar: I think we have some subtle differences between the proposals jarhar: We don't want to burden the dev to force them to apply appearance: base to put appearance in two different places jarhar: I think that's the fundamental disagreement annevk: I think it's hard to go into this with this discussion without knowing Google's longer-term vision annevk: on our vision the picker and the controls are individually stylable annevk: but Google has mostly focused on select masonf: Few things, I think we really like the idea of doing it all at once, but it sounds difficult masonf: I'm glad it seems ok to do appearance: base-select to carve out of that masonf: I think we should do the same for other controls <jarhar> would putting appearance:base on ::picker() also apply to the main element work? masonf: One thing we've discovered with <select> is that they're not independent masonf: it's difficult to allow customization of the in-page thing masonf: without accounting for the whole popup and everything masonf: e.g. for date pickers the most common use case is displaying something else along the date annevk: that feels like a new semantic capability for that control annevk: we're just talking about styling the page controls as they are today masonf: Our opinion is that for most things styling the picker is the main wanted feature masonf: e.g. if you want a flag on a `<select>` option annevk: We might be seeing different feedback annevk: I've seen feedback where authors are just trying to get basic form styling working across UAs and that's hard annevk: it has been hard for a long time, even just having full control of the box masonf: I've heard the same feedback for stuff like checkboxes masonf: but it's possible, people do it, they put that work <ntim> `::picker(select) { appearance: base }` is pretty straightforward to write honestly, and you can already write whatever styles you want on `select` masonf: The things that are impossible are the things people complain about masonf: and are the things we should focus masonf: If we just did some of the work for the date picker for example then we'd have complaints about not having done the work for the popup annevk: That seems it'd need additional markup which could be the opt-in annevk: We will continue to add new features to these controls annevk: To me the sooner we get the appearance: base stylesheet annevk: the better, then we have the infra for new markup features we can opt them into that masonf: I think that might be too optimistic, devil is in the details masonf: I want to have the appearance-<control> fallback plan in place <annevk> FWIW, I saw it recently on British Airways iirc where they didn't bother with customizing the popups <masonf> Anne: british airways uses native <select> and therefore *can't* style the popup dandclark: Echoing what masonf said, the feedback we get is about styling the control dandclark: The thing that worries me is the long-term dev experience dandclark: If we do base-{select,range,...} there's a path to make appearance: base apply to anything dandclark: If we have the different picker stylability, do we have the same long-term possibility of not having the double opt-in? una: Echoing a lot of what dandclark mentioned una: One thing that hasn't been brought up is how intricate the picker and the buttons are una: splitting that opens a can of worms for a lot of the controls una: even for annevk's example, they don't do it because they can't una: I think that's a testament of why they need to be tied together una: The more that we dig into it the most nuances we find una: the pickers are very tied to their controls <ntim> I think people tie the pickers more to modals rather than their in-page controls when it comes to writing design systems dbaron: There was something annevk said about the complaints developer have being things about simple styling dbaron: I think one of the things that happens when you focus on the complaints that people have is you focus on things that people could /almost/ do dbaron: there's another way to look at it dbaron: why are authors building their own widgets rather than using the native? <masonf> Great viewpoint. Developers build their own: selects, date pickers, color pickers, etc... dbaron: I think that's an important q because using the built-in has a lot of advantages dbaron: and when you ask that you get to different conclusions dbaron: hard for me to say what the Google strategy is, but I think there's a lot of thinking about figuring out what to do about these users and making them possible dbaron: and I think that explains some of the different conclusions about why tying them together is important dbaron: that might involve other semantic changes, like what masonf mentioned about date pickers emilio: I think I also added myself to the queue to react about styling in-page buttons being difficult. emilio: I think that's true of many controls, such as range. emilio: but others are fairly consistent emilio: and to be honest the ones I'm aware are difficult to style are the ones that don't have pickers, like range and slider and progress etc. emilio: people want to do cool stuff with them emilio: I think I'm with una that splitting customizability, esp. if we allow pages to use appearance:base only on the picker, that seems like a can of worms we don't want to get into. <ntim> emilio: I brought this up last time, but using the native picker can be a design choice chrishtr: I'd like to focus on the points of agreement chrishtr: looking at the latest comments chrishtr: fantasai rephrased everything to three bullet points ntim: That's the opposite of what I meant though ntim: The main disagreement is about whether the select keyword would apply to both or just the select ntim: I wonder if we can resolve on what fantasai commented on the issue, then discuss about having a single or two opt-ins annevk: I think you can get it in one line :) <dbaron> fantasai's comment was https://github.com/w3c/csswg-drafts/issues/10440#issuecomment-2303554166 (I assume) <ntim> This is the opt-in in how we ideally see things: `::picker(select) { appearance: base }` <ntim> or `select, ::picker(select) { appearance: base }` if you the base stylesheet on the select annevk: I still don't have a satisfactory answer on how to make appearance: base apply to everything without tackling all pickers annevk: like color annevk: I like the focus on the individual controls annevk: but it misses looking at the whole annevk: which is what leads to this clash annevk: for the color thing you need to know "is there a picker", opt in the picker, did the UA decide to honor my request for custom picker annevk: so appearance base would end up computing to auto on the picker for e.g. color inputs on a watch <ntim> Then in the future once all the pickers are stylable, people can just use `::picker`, along `dialog` and whatever modal-like things exist astearns: Any reservations on fantasai's comments emilio: I think the second point is the concern una and myself were talking about, which would allow a base-appearance picker without a base-appearance control una: I think we don't want to block <select> on figuring out the color picker for example chrishtr: It's not blocking, we would just not support the ::picker(color) syntax emilio: Not sure we want the ::picker() { appearance: base } unconditionally astearns: Let's bring this back to the issue and try to get consensus there
Received on Sunday, 25 August 2024 18:03:40 UTC