[CSSWG] OpenUI-WHATWG/HTML-CSSWG Meeting 2024-05-23

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


CSS UI- appearance: base to enable interoperable styling of
    controls/components (Issue #5998)

  - The group resumed the conversation to reach a decision as to if the
      best approach to styling of controls/components is opting in via
      a CSS property
  - Anne shared a presentation outlining webkit's vision for
      appearance:base (
https://annevankesteren.nl/temp/stylable-form-controls.pdf )
      to ground the group in a common purpose and language.
  - The biggest concern with the presentation was the approach to
      - Pickers were presented as being specced later than other
          elements and some folks thought it needed to be tackled
      - The feature rollout for pickers was discussed and it was
          clarified that the proposal intended a pseudo element to
          allow detection.
      - A separate issue will be opened to address pickers so this
          discussion can continue.
  - There was discussion around the difference in implementation
      between appearance:none and appearance:base to avoid some compat
  - Achieving the full vision may require HTML work, but there was
      agreement that the opt-in should be in CSS.

  - RESOLVED: Use css to opt into styleable mode


Agenda: https://lists.w3.org/Archives/Public/www-style/2024May/0018.html

  David Baron
  Tantek Çelik
  Keith Cirkel
  Daniel Clark
  Brecht De Ruyte
  Chris Harrelson
  Robert Flack
  Mason Freed
  Aditya Keerthi
  Travis Leithead
  Tim Nguyen
  Olli Pettay
  Simon Pieters
  Alan Stearns
  Miriam Suzanne
  Anne van Kesteren
  Luke Warlow

Scribe: chrishtr



appearance: base to enable interoperable styling of controls/components
  github: https://github.com/w3c/csswg-drafts/issues/5998

  masonf: Joey is doing most of the work on these issues, but is out
          today so I'm covering
  masonf: There are a number of questions for the styleable form
          controls area, but 5998 will help to make concrete progress
          on a key question about opt-in
  masonf: this is about opting in via a CSS property
  masonf: there are various other ways to opt in that were proposed on
          the issue, and I'd like to get a resolution that the css
          property is the way forward
  masonf: We could as subsequent resolutions agree on the names of the
          property and values, but using a css property is the key next
  <dbaron> Joey's slides 2 weeks ago were

  astearns: Should we go to the presentation now for Anne?
  annevk: Need about 10 minutes for the presentation
  chrishtr: annevk does this make sense as a goal?
  annevk: oh yes; the presentation talks about the long-term vision,
          and styling is a part
  annevk: Styling opt-in via css makes sense
  fantasai: Deck is about general concepts, best to get started

  <astearns> https://annevankesteren.nl/temp/stylable-form-controls.pdf
  annevk: We've been discussing styleable form controls within the
          webkit team
  annevk: Want to lay out a long-term vision for all controls, not just
  annevk: Gives direction for what we want for web developers in this
  annevk: Motivation: markup for form controls is haphazard, want to be
          uniform and consistent
  annevk: also want to hear from others what they think
  annevk: Terminology: in page controls are part of the layout tree,
          and then there is the picker which is overlaid on the page
          for some controls.
  smaug: Pickers in an OS window or different process, or in-page?
  annevk: Depends on the situation
  annevk: There is a "base" style sheet
  annevk: style sheet will be wireframe-like, meets a11y and i18n
          criteria, supports dark mode
  annevk: It's a starting point from which developers can add
  annevk: needs various pseudo elements and opt-in
  annevk: Opt-in would be appearance: base, which also opts into the
          base style sheet
  annevk: for styling pickers we were thinking that these need pseudo
          elements for overlay boxes
  annevk: Maybe these styles are available for appearance:none mode as
          well as appearance:base
  annevk: might introduce inline control theming first and then add
          styling for pickers later
  annevk: Think we might be able to do all of the in-page controls in a
          timeframe of 1-2 years
  annevk: including base style sheets
  annevk: After that would be pickers, but might not be able to do them
          all at once or quickly
  annevk: Would be great to hear more long term visions from others;
          alignment and agreement will ensure good web developer and
          user experience
  annevk: Don't mean to impede or slow down the progress made on select
  annevk: We can do both the short term work already done for select as
          well as define a pattern for other controls

  astearns: Point of order, would like these presentations to be in the
            issues before the meeting rather than presented live
            without opportunity for prior feedback and discussion
  masonf: +1 to that point

  masonf: Thanks for the presentation, the deck looks mostly aligned
          with what my team was thinking
  masonf: One possible departure is pickers
  masonf: One important design consideration we think is important is
          being able to put arbitrary content in pickers if they are
          not part of the page
  masonf: The in-page part of the select is styleable (but only allows
          text content, which is a restriction)
  masonf: the picker is the main area that is not styleable
  masonf: Not sure the priority is in the right order therefore, since
          the deck proposes doing in-page first and then pickers

  fantasai: Want to provide some more context about what webkit is
  fantasai: Incremental rollout is important, that is a consideration.
  fantasai: Talked with Tim and Jen about all this and there were some
            concerns about DX of per-control values
  fantasai: want the end state to be easy to use
  fantasai: want things to be consistent, so that might meaning
            shipping stuff in a batch
  fantasai: For pickers it might be hard but think we can do all of the
            form controls at once for in-page parts. This is part of
            why the proposal for 2-phase
  fantasai: Agree that the picker being styleable earlier for select
            since that's a strong need for developers; and also it's a
            lot easier to do because the parts all have representation
            in the DOM
  fantasai: ::picker pseudo element suggestion is not enough to style
            all pickers and there'd need to be pseudo elements for the
            important parts of them also, ::picker is just meant to
            represent the overlay box itself

  florian: I like the direction this is going in, was previously
           nervous about base-*
  florian: seemed like a design smell to enumerate all form controls as
  florian: we ended up having some special values in the existing
           appearance property due to compat
  florian: Perhaps we do need a few special cases to get there, and we
           could do that if needed for specific controls that are hard
           to evolve without compat problems
  florian: There is a desire for more flexible content to put into
  florian: Want to talk more about the ability to opt into more
           flexible content rendering as triggered by a css property
  florian: could work, but want to learn more about it
  florian: If pickers need to be done not all at once can we do it with
           one value?

  <fantasai> Slides:

  <emilio> Why not different pseudo-elements like ::select-picker and
           so on?
  <fantasai> emilio, 2 reasons - 1 have a common prefix to represent
             the set, and 2 - want to have the ability to style them
             all (eventually)
  <emilio> fantasai, doesn't that introduce the same compatibility
           issue you're trying to avoid? (where we add a new picker in
           the future that now get weird styling the author didn't
  <fantasai> emilio, ::picker(*)? Yes, which is why we wouldn't
             introduce it now and take it under consideration for

  <TabAtkins> Ah, I didn't get that ::picker(ident) was a
              specialization there, okay.

  <zcorpan> Would @supports(::picker(select)) work?
  <fantasai> zcorpan, @supports(selector(:::picker(select))) should
             work, yes

  <Luke> Does * or ::picker(*) match any of the pickers? I would
         assume no?
  <fantasai> Luke, not currently, no but we may get there if we can
             make them enough of them styleable that adding that later
             wouldn't cause compat problems

  annevk: Replying to feature detection for pickers, idea was to have
          multiple values, but they would be part of the pseudo-element
          name, not the value of a css property
  annevk: If your platform or browser doesn't support it yet then the
          pseudo element would not be present
  annevk: for example, ::picker(file) might not exist

  ntim: `::picker(select)` would be exist along with all the HTML
        parser changes / <selectedoption> Chrome has worked on, but in
        our vision, what opts in rendering the picker customization
        would be `::picker(select) { appearance: base/none }` (not
        `select { appearance: base-select }`

  dbaron: When you were talking about the in-page then pickers plan,
          one point I'd like to raise is that the demand for
          customizing pickers depends on the form control
  dbaron: For example, developers don't seem to really want to
          customize a color picker right now, but they do really want
          to customize date pickers
  dbaron: they also want to customize content for date pickers, e.g. by
          supplying pricing associated with dates
  annevk: This might involve new html elements, is that what you're
  dbaron: Not sure, but maybe
  dbaron: If we work on pickers and then need to change in-page
          aspects, then would we need a second phase of opt-in and lose
          the opportunity to upgrade?
  annevk: Don't think so because the changes would be semantic/HTML,
          and so should be allowed to extend existing built-in modes
          and not just the styleable mode
  annevk: There will need to be a base style sheet and then for each
          additional feature there might be additions to style sheets
  <ntim> dbaron- Our vision allows for tackling pickers first (through
         `::picker(datetime) { appearance: none/base }`)

  flackr: Interesting that you brought up non-in-page pickers
  flackr: Would that mean allowing custom content in non-in-page
  flackr: For select we're pursuing in-page pickers to make them
          customizable with content, but appearance: auto and date
          pickers are in another window
  annevk: In styleable mode the picker would be part of the layout tree
  chrishtr: In other words, in styleable mode everything would be part
            of the document layout tree; the distinction in the deck
            Anne presented is just about project ordering and features,
            not about rendering model

  emilio: Do you envision appearance: base for buttons being different
          than appearance: none? how much change to style sheet?
  fantasai: For simple controls the difference from existing style
            sheets would be minimal. For radio buttons it'd likely be
            more substantial because currently they disappear in
            'appearance: none'
  emilio: Difference between appearance:none and base not particularly
          important, we can just agree on styles that are shared in
          most cases?
  fantasai: appearance:base should be wireframe, doesn't need a reset
            style sheet, meets basic requirements, but not at all
  fantasai: appearance:none has compat problems, hence appearance: base
            changing styles
  emilio: Aware of Google's implementation approach which seems
          sensible, would the changes envisioned by webkit work with
  annevk: Joey's approach should work for anything?
  masonf: Yes but devil may be in the details
  emilio: Could result in overly complicated browser engines if there
          are a lot of or complicated styles in appearance:base mode

  brecht_dr: Idea of the picker that raised confusion for me was that
             in open ui we played around with elements targeted with css
  brecht_dr: Will we be able to do this in general, and allow
             no-datalist markup?
  brecht_dr: The proposal seems compatible with this, is that right?
  annevk: Seems so, but new pseudo elements also needed sometimes? or
          maybe optgroup etc can be targeted directly
  annevk: Base style sheet also works with existing controls, so should
          be able to target anatomy of the existing controls
  fantasai: We'd probably want a pseudo element for the drop-down arrow
  fantasai: Should be consistent with the datalist model, shouldn't
            need to care whether developer provided that element or not
  brecht_dr: If there if flexibility in the system then perhaps picker
             and in-page should be released at the same time for a
             control to make things simpler for developers?
  fantasai: appearance:base for all things can be done, but also
            bringing up the picker for select because it's important
            and further along, and also because the components of the
            picker are already in the DOM -- we don't have to figure
            out the internal structure of the picker with pseudos or
            something, it's right there in the page
  fantasai: If we use ::picker(select) { appearance: none; } to opt
            into styling select, then we don't need to introduce
            'appearance: base' to enable styling the picker

  Luke: Some things said resonate. Won't solve every problem with CSS,
        need HTML changes also
  Luke: Makes sense to do in-page first generally, and in particular
        because there are lots of controls without significant pickers
  Luke: lots of customizing for date pickers is new behavior, not
        just CSS
  Luke: Base styles is a good start rather than the finish
  Luke: Like the idea of the ::picker pseudo selector/element, solves
        some future compat problems
  Luke: Considering buttons, there are differences today among browsers
        and platforms, matching in appearance:base mode would be great
  Luke: Wondering again how much can be in CSS

  masonf: Question: my understanding from the presentation is that with
          ::picker there'd be a standardized shadow dom
  masonf: also heard there would be arbitrary content, could you
  astearns: Let's discuss picker questions in a new issue
  masonf: Sounds good
  <fantasai> mfreed, we don't have a specific plan for the various
             pickers, we just want to use ::picker() as a way to opt
             into styling them one at a style

  masonf: Proposal is to avoid having separate values for appearance
          because that's not ideal, and then boil the ocean and would
          be hard to do all at once
  astearns: What I heard is let's boil as much as the ocean as we can
            but being reasonable. e.g. maybe we can special case a few
            situations like select
  fantasai: Not trying to boil the ocean, just trying to boil the
            minimum amount of ocean necessary to give developers a good
  annevk: Not saying we should extend all form controls in as fancy a
          way as select needs, just that we'd achieve the basic
          styleability of existing controls
  masonf: Think this might end up more complex than anticipated,
          because we might need a new element for even simple cases
          when we realize it should be possible
  fantasai: Still need to style existing elements
  <fantasai> If we're concerned about select specifically, the issue is
             styling the picker, so we would use `::picker(select)
             { appearance: none; }`
  <masonf> The concern is that people do *{appearance:base} and then it
           breaks later when a browser starts supporting it.

  <zcorpan> What I wanted to say: (1) if priorities suggest doing
            in-page pickers for only some of the controls, we can have
            `base` and `base-foo` (for all controls when implemented)
            so authors can feature-check with @supports but also can
            use `base` for any control. (2) Does appearance: base turn
            off button layout magic or no?
  zcorpan: Should we use appearance: base as a trigger to turn off
           button layout
  emilio: Didn't Ian have a plan to do that w/o new CSS?
  chrishtr: Yes
  <zcorpan> light-dark()-like seems OK
  florian: Should we do it in CSS? Yes. Need more discussion about
  <masonf> +1

  RESOLVED: Use css to opt into styleable mode

  astearns: I would like to have a separate issue for ::picker()

  <ntim> I think `::picker(select) { appearance: none }` would allow
         Chrome to ship select first, without introducing a new
         `appearance: base-select` value or trying to tackle the whole
         of `appearance: base` first
  <tantek> I tried different 'appearance' values for different clusters
           of controls as well as specific controls, literally in the
           earliest versions of the appearance property. This does not
           work for various reasons. Unfortunately most of that
           experience (though documented in www-style / w3c-css-wg /
           various CSS UI drafts) is 20+ years old
  <tantek> here you go, wow literally 20 years ago merely days ago:

Received on Thursday, 23 May 2024 23:37:41 UTC