[CSSWG] OpenUI-WHATWG/HTML-CSSWG Meeting Minutes 2024-08-22

=========================================
  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