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

=========================================
  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: Pseudo-element selectors apply only to the UA-provided
              elements in a particular role (Issue #10462:
              Pseudo-elements for stylable select)

Form Controls
-------------

  - The group discussed the proposal to have incremental opt in for
      elements with pickers using ::picker pseudo (Issue #10440:
      Styling form control pickers).
  - Several folks spoke about author needs in this space. Having to set
      several properties increases the burden on authors, especially at
      smaller firms with limited resources. However, there has not been
      specific research on this topic so there could be room to learn
      more about author needs and wants.
  - Additional to the author needs, there was also concern expressed
      that if the first opt-in releases aren't scoped to specific
      element types, authors would use a broad opt-in and it would lead
      to compat problems when functionality expands.
  - There was broad agreement that appearance:base is the north star
      that the group should be working toward, though some disagreement
      on how long/hard that will be to achieve.
  - As the call concluded, there was a proposal to ship
      appearance:base-select just for selects as an increment and then
      ship appearance:base for everything. There was support expressed,
      but the call ran out of time for further discussion.

===== FULL MEETING MINUTES ======

Agenda: https://github.com/whatwg/html/issues/10536

Present:
  Joey Arhar
  David Baron
  Keith Cirkel
  Emilio Cobos Álvarez
  Elika Etemad
  Mason Freed
  Chris Harrelson
  Michael Smith
  Greg Whitworth

Chair: gregwhitworth

Scribe: keithamus

OpenUI-WHATWG/HTML-CSSWG meeting
++++++++++++++++++++++++++++++++

CSS UI
======

Pseudo-elements for stylable select
-----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10462

  jarhar: Both the pseudo elements for appearance base mode. Two
          issues, ???... should these elements cover the author
          provided thing or the button/datalist not be a target of the
          pseudo elements
  jarhar: The author provided button element; should the element target
          the author provided or just the fallback? There are
          trade-offs here.
  jarhar: Could be developer convenience but could have complications.
          How does it work with animations, subtree, etc.
  jarhar: There might be styles we could fall back but not both, so
          we'd need to invent some internal pseudo element to target
          the fallback
  jarhar: Might be better for developers if it targets both

  gregwhitworth: When you go to change it, its no longer the element. I
                 don't know the technical reasons emilio is pushing
                 back on, but as a dev when I replace it I now own that
                 element so wouldn't expect pseudo to work.

  fantasai: We have several elements that replace default; button,
            dropdown, I think we have to think about when a dev is
            styling they might not know exactly how the control is put
            together.
  fantasai: It might be implemented as native for a while, upgraded to
            datalist, you didn't change your stylesheets, you're using
            a component library...
  fantasai: I can definitely see why you'd want them to match. The
            other technical concerns are certainly real.
  fantasai: From authoring it would be more convenient and more robust.

  emilio: I think I get both points. As author, I agree with Greg but
          if you have more generic styles it can be nice to have a
          single selector. As a component library, presumably they'd
          export the dropdown in some other way e.g. shadowpart or
          shadowdom so you cannot target directly yourself.
  emilio: Given there's no precedent. Given the complications; like we
          have a bunch of APIs for exposing pseudo element stuff. Eg
          getanimations with subtree true returns pseudo element
          animations, but it would be weird to behave that way... you
          kind of want the element reference if you have the pseudo but
          can't do that with shadow root
  emilio: Causes inconsistencies with various APIs like this.
  emilio: Plus there are usecases for e.g. targeting built in UA one.
          It's just less complicated to explain if you use pseudo to
          match the provided, and otherwise not.
  fantasai: I meant component library in a much more general sense,
            like not just web components but CSS libraries or templates
            or something
  emilio: But then changing implementation from built-in datalist to
          custom one is a breaking change but no more changing than,
          for example, changing a button to a link
  emilio: If you're using a 3rd party library you need to be mindful of
          these changes and breaking the API

  jarhar: Sounded like people are in favor of both sides?
  gregwhitworth: We could straw poll or take it back to the github
                 issue.
  fantasai: From the agenda it looks like we have this one issue which
            is a superset of lots of small issues. Can we split this up?
  gregwhitworth: You want to tackle this as 4 separate ones?
  fantasai: If they're independently resolvable filing separately makes
            it easier to focus on each one
  chrishtr: We could resolve on one of those
  gregwhitworth: Would we want to have a default position?
  gregwhitworth: if an element gets replaced, the pseudo element being
                 applicable irregardless of which one it is - do we
                 want to resolve on that first?
  jarhar: That's one of the three.
  fantasai: I'd agree we should be consistent
  fantasai: As for which way, I feel like we've heard from two or three
            people
  jarhar: I think we discussed this in openui before, a vague memory of
          people preferring the ???

  keithamus: If we allow the pseudo's to target the author provided is
             the way to differentiate between author and useragent
             provided?
  fantasai: Yes, because you could...
  <fantasai> ::button:not(button)
  keithamus: Is that more difficult than than the reverse
  keithamus: If I want to select for the built-in verse user provided;
             which one is more complicated

  emilio: I think especially since you cannot use pseudo elements in
          :not()... I think fantasai's suggestion might not work
          without changes to pseudo syntax.
  emilio: We don't reveal tag name of the pseudo element. You'd need
          select:has(datalist:thepseudo) which is kind of annoying
  <emilio> `select:has(> button)::button` or so

  chrishtr: So this would be in favor of not ???. Like reducing
            complexity
  chrishtr: If there's additional engine complexity in trying to match
            both at the same time, let's go with just the built-in.
            Let's developers in a straightforward way to differentiate
            and avoids complexity in the engine

  gregwhitworth: Curious; two jobs to be done: when would I really want
                 to differentiate? To interrogate if there's a user
                 provided vs user-agent provided element.
  gregwhitworth: I get fantasai's use case. The component library,
                 there's a contract there... but its low probability.
                 What's the use case though keithamus?
  keithamus: I don't think I have a good answer to that to be honest

  dbaron: If we go down the path of making pseudo only match built-in,
          if the author provided ones are in some cases - I don't know
          how complex - but if they're complex they could have a pseudo
          class, to match an existing element. A pseudo class is a
          thing that matches what you already have, vs a pseudo class
          to match an element that exists in the UA shadow. One way to
          do it.

  emilio: I don't think the rules here are particular complicated. You
          need to be a direct child of the select element, so I don't
          think the pseudo class is necessary. The reason for
          interrogating if it's a built-in, if you're not a built-in
          you can do more complex styling of the innards. If you have a
          big CSS codebase and 2 ways of addressing the same thing in
          subtly different ways, it's not amazing but you could want
  emilio: to target the built-in with basic styles and non-built-in for
          more complex styles. If the pseudo matches both you need to
          undo the pseudo rules with non pseudo selectors.
  <chrishtr> +1, good point

  <fantasai> Option 1: Pseudo-element selectors apply to both the
             user-provided and UA-provided elements in a particular role
  <fantasai> Option 2: Pseudo-element selectors apply only to the
             UA-provided elements in a particular role
  <fantasai> Option 2.1: Also provide a pseudo-class to select to
             user-provided (and UA-provided?) elements in a particular
             role.
  gregwhitworth: Two foundational positions for this base one that
                 informs the 3 other issues. User submitted will or
                 won't apply. Should we take this back to the issues? I
                 feel like I'm in favor of _not_ having them to apply
                 to user-provided. Is there a strong reason to go in
                 the other direction?
  gregwhotworth: does anyone have a strong position
  gregwhotworth: does anyone oppose doing a straw poll?
  fantasai: I didn't fully catch what dbaron's position on pseudo
            classes was.
  jarhar: I think it could differentiate what the element was selecting
  <fantasai> 1.1: And also provide a pseudo-class on differentiating
             whether it's a real or pseudo element.
  dbaron: You could do either way! But perhaps it's better to leave the
          sub-options out of the straw poll.
  gregwhitworth: For straw poll we'll just do the main options. Please
                 put option 1 or option 2 in IRC
  <chrishtr> option 2
  <emilio> 2
  <jarhar> 2
  <ntim> 2
  <fantasai> abstain
  <keithamus> 2
  <gregwhitworth> 2
  <astearns> abstain
  <dbaron> 2 (weakly)

  RESOLVED: Pseudo-element selectors apply only to the UA-provided
            elements in a particular role

  emilio: For the library use case, I think we resolved on the pseudo
          element kind of a part-like pseudo. If we were really
          concerned about providing the same API as a component library
          we could make exportparts work to expose the inner pseudo
          elements. Then you could expose the same API in both
  gregwhitworth: Does this resolve the other issues jarhar?
  jarhar: I think it could be worth raising 1 new issue for each
          pseudo, asking should it exist and what should it be named.
          With that in mind we can close this issue

  chrishtr: What are the three issues?
  chrishtr: 1 is the one we resolved
  chrishtr: 2 is do we need them
  chrishtr: 3 is what are their names?
  jarhar: Yes
  chrishtr: Are we ready to discuss 2 or 3 yet?
  gregwhitworth: Yes I think it's a bookkeeping issue
  chrishtr: jarhar could make issues after the meeting and copy the
            resolutions?

Form Controls
=============

Styling form control pickers
----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10440

  jarhar: I'd like to get to the second issue because it can affect how
          we name the pseudos.
  jarhar: Proposal to have incremental opt in for elements with pickers
          using ::picker pseudo which you could add appearance:base on
          to get the new styling for the picker itself.
  jarhar: so this would be alternative for e.g. appearance: base-select
          opt in for each rule
  jarhar: One problem is that Chrome is looking to ship select first,
          so opt in for page pickers is not that helpful
  jarhar: on top of that Una posted a comment about it being more of a
          developer burden for developers to do this on each picker
  jarhar: IMO we should have appearance:base on root element for
          everything without incremental opt in
  jarhar: The push back was incremental opt in but una and anne are
          talking about the same issue regarding opt in
  jarhar: ???
  jarhar: the author has to remember more things for each element.
  jarhar: The whole thing is brought up as a need for incremental opt in
  jarhar: but we can add support for supported elements, tweak style to
          show it didn't apply properly or isn't supported on this
          element yet.
  jarhar: I think it simplifies it.

  fantasai: The issue isn't can we feature detect, incremental opt in
            is for compat reasons. Authors will use a more general
            selector than is needed then opt in, but then we end up
            with "we can't ship appearance:base" on, say, date
            controls. Now we need a _new_ keyword appearance:
            base-no-really including date pickers. That's _why_ we need
            an opt in.
  fantasai: The reason we split into in page and not-in-page. We
            believe we can pull together the necessary standardization/
            implementation work to do this within a reasonable amount
            of time, but styling pickers is a multi year project.
            Something we'll have to do incrementally
  fantasai: It may be that developers are fine with not-in-page pickers
            but want to style in-page
  fantasai: ???
  fantasai: That's why its incremental on the picker. To enable
            incremental styling of the in-page then add the picker
  fantasai: The reason we have picker with a bunch of identifiers is
            that we don't anticipate being able to tackle handling all
            of the pickers consistently and thoroughly in a single ship.
  fantasai: We can make the picker identifier optional after a certain
            point, authors can just use ::picker without the keywords,
            but this gives us a gradual transition towards that.
  fantasai: Allowing us to ship in pieces.

  una: Thanks for the explanation fantasai. I've been playing with it
       quite a bit, the biggest aversion to the current proposal is
       having to do this in multiple places and remembering the names
       of all the pickers, in order to get this to work properly
  una: Ideally authors would not have to remember that and just do it
       in one place
  una: I think jarhar mentioned doing @supports to incrementally adopt.
       We can't use @supports to detect outside of CSS. What are your
       thoughts there?
  <fantasai> Totally agree that this would be better. We just think
             it's not possible due to anticipated compat restrictions.
  <fantasai> But at least this gets us to a world where that can be
             possible in the future.
  jarhar: @supports whether appearance: base supported on specific
          elements. If we ship select first and you put it on input
          type=range that'll still be auto. We add an @support and we
          can say that works, we still need a unique identifier for
          that.
  jarhar: then we make a new @supports for each one
  jarhar: in your @supports rule you could style each one.
  jarhar: Then if you put html in your select is a separate html thing,
          it would still support the new structure just render in the
          native browser way

  una: So would this work with the picker opt in?
  una: So Anne mentioned putting appearance:base on both the base
       element and the ::picker(type-of-picker). Is it possible to make
       it just in one place, e.g. the pseudo element
  fantasai: That would only select the picker, you could apply styles
            to the picker only. Setting appearance base on that would
            make the picker base, but the in-page control still auto
  fantasai: even before pickers are stylable we want the in-page
            control to opt into appearance:base. We think authors want
            in-page styling _the most_, over the pickers.
  fantasai: Obviously they want both but in-page seems to be the most
            desired.
  fantasai: Could we have it magically propagate? Maybe but that would
            be super weird
  una: And the other way around, base on the in-page propagating to
       picker doesn't resolve the issue you're bringing up?
  fantasai: Yeah. Its possible authors don't want to put in the effort
            to style pickers, just in-page, so it's useful to have the
            difference, but it also allows us to incrementally ship
            these features. So we don't run into compat issues

  una: I'm curious if you've had feedback from authors about if they
       don't want to style pickers vs in-page?
  fantasai: We haven't heard that specifically but the main thing
            driving the design is how to opt things in with minimal
            impact without memorizing weird keywords, which we agree is
            undesirable but we need some way to handle opt in
  <ntim> I could see developers wanting a native picker and base-styled
         in-page
  <ntim> native picker have special capabilities such as expanding
         outside of the window bounds for instance
  jensimmons: We've not done specific research for e.g from big
              corporate partners but remembering what it's like to be a
              web designer on a smaller budget, everything in-page
              needs to be represented in brand but budget restricts
              from designing every single thing, so we might want to
              style the select but not be able to style the picker.
  jensimmons: bigger projects will, e.g. delta really wants their
              calendar to look like a delta calendar
  <fantasai> +1 jensimmons
  jensimmons: but where budgets are much smaller I think it'll be
              common that they want in-page styles but no budget to
              worry about styling the picker
  una: I see where you're coming from. I'd like to do more research.
       I've heard it's currently hard to style the picker, not the
       button
  jensimmons: Asking for select menu, asking for calendars, this is
              what we hear a lot but thinking through styles - it's
              difficult. Styling buttons can be styled however you want
              but oh, unless its input type=file.
  jensimmons: It would be very annoying to roll out changes to all
              controls one-by-one. It's a better project to do all at
              once.
  jensimmons: but its impossible to do ALL in-page and pickers all at
              once.
  jensimmons: Tackle all in-page controls all at once and pickers one
              by one

  jarhar: fantasai mentioned ::picker for compat for incremental opt
          in. All in-page first, then incrementally with pickers.
          masonf & chrishtr - correct me if I'm wrong but we can't do
          all in-page at once? And we want to ship select first? Still
          seems best for developers to me to have appearance base on
          root element, or ::picker(select) apply its value to the root
          element, to ship select first.

  masonf: Important to remember this is compat. We can do
          appearance:base and eat the risk, or two options:
          appearance:base-something or ::picker(something). Both are
          ugly but both work
  masonf: but working on select for 5 years and talking to developers.
          All in-page controls are pretty stylable. The really tricky
          bits are stuff like select where there's a picker
  masonf: For example putting rich content in the picker shows up in
          the base control.
  masonf: I find it really unlikely well be able to ship all in-page in
          a year. I think each will have to be shipped holistically, in
          its entirety, picker and all.
  masonf: Having said all that, if that's all true it seems to me that
          we should make it easy for developers to opt in to each
          control.
  masonf: Let's make it as easy as we can for developers
  <chrishtr> opt-out is a good idea

  gregwhitworth: I think there's 3 options. I haven't heard not caring
                 about the picker a ton, but I personally lean
                 towards... we all want appearance:base, I want to do
                 *{appearance:base}. But to go to una's point, if I did
                 that on select I'd expect it to apply to picker.
                 Doesn't mean picker pseudo can't exist, we don't have
                 to throw the premise of opt-in/out for pickers, but I
                 agree with masonf
  gregwhitworth: So before we even talk about base we have to talk
                 about the parts, e.g. file. How do we lay them out?
                 What's the base styles for that?
  gregwhitworth: Some may go faster than others but there is such
                 disparity between even UAs as to what they do
  gregwhitworth: So I think there are 3 options, appearance:base being
                 north star, but same for gap, flex-gap grid-gap sucks
                 let's just use gap...
  gregwhitworth: but we'll need that for appearance:base
  <chrishtr> opt-out gives a way to get a native picker

  ntim: I want to emphasize on the value of the pickers having a
        different appearance. A native picker could be a design choice.
        e.g. on visionOS you might want the nice native picker going
        out of system bounds. There's value in picker being native.
  ntim: Having appearance:base toggling on everything goes against that.
  ntim: From a design systems view pickers will likely be different
        going control-by-control.
  gregwhitworth: Most design systems to have base foundationals
  ntim: Yeah I am saying most design systems wouldn't want to style a
        specific control, in-page and picker. They'd separate by
        in-page vs picker.
  ntim: You don't want 1 control to have native, and others to have
        base-styled. You want consistency.
  ntim: like in the future I would see systems libraries doing
        *::picker{appearance:base} or *{appearance:base} for in-page.
        This is the future I see.
  <gregwhitworth> ntim I want to +1 that the picker feature possibly
                  being useful, I think I disagree with them being
                  native by default
  <ntim> gregwhitworth: it's already the current default though
  <jarhar> we could make select { appearance:base; } imply
           select::picker(select){appearance:base} and then you could
           also apply select::picker(select){appearance:auto} to make
           the picker go back to the native appearance
  <jarhar> there are also existing ways to style the in-page part of
           select with appearance:none which we could extend with the
           new content model that allows an author button

  una: +1 to appearance:base being north star. Changing way to opt into
       form controls. Theoretically users would be able to connect any
       button to the picker using invokers, that would give them
       control for any page control, whatever control that is. We
       talked about selectoption linking to any form control, e.g.
       outside of select, controlling the control
  una: This gives users more capability to customize in-page control vs
       pickers
  una: Right now we don't give users choice on picker
  una: Currently there is some styling with appearance:base-select.
       Users don't necessarily need to customize it
  una: This could open the door for new controls having custom styles
       for appearance:base. We could do more there, e.g. 3d...
  una: ???

  jensimmons: What's great about appearance:base is it switches the
              very different operating system controls - per platform -
              its very hard to override those. appearance:base gives
              everyone a consistent control, same in each browser
  jensimmons: I'm responding to hearing people say it's not hard to
              design in-page controls. Putting your own styling on e.g.
              checkboxes right now is annoying. Doing it across all
              would be very valuable to all developers
  <jensimmons> And Apple is working on in-page controls now, coming up
               with a proposal to share when it's ready.

  fantasai: I think we at Apple generally disagree we can't ship
            appearance:base all at once. We think its doable within the
            next year or two, and not take as long as doing all of the
            pickers. In terms of select specifically, it's special,
            Google's been working hard on it but it's also a form
            control where the picker and all components can be
            represented as elements in the page.
  fantasai: most other form controls have pickers with UA magic
  fantasai: It might be reasonable to ship appearance:base-select just
            for selects, while we work on the rest, then ship
            appearance:base for everything
  <jarhar> agree
  fantasai: so we can split the difference
  <masonf> +1 to that approach!
  <chrishtr> +1 to base-select
  fantasai: We don't want values for every form control but a
            short-term phase for select seems reasonable and acceptable.

Received on Saturday, 10 August 2024 15:24:57 UTC