[CSSWG] OpenUI-WHATWG/HTML-CSSWG Meeting 2024-05-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.


Presentation on styleable <select>

  - jarhar gave a presentation on the background and use cases for a
      styleable <select> as an introduction to other agenda topics for
      the meeting. The slides are available here:

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

  - The discussion for issue #5998 was centered on answering some
      questions and re-grounding everyone in the history of this topic
      since conversations had previously happened across groups
  - Some of the historic and current doubts raised were around future
      compatibility and the property being too specific as well as
      doubts around accessibility and ergonomics. Many of these
      concerns, though not easy, have been thought through and
      addressed in the proposed future state.
  - The next step is to see if there is agreement at a conceptual level
      to add this to CSS with details on exact properties and behavior
      to be defined in a separate issue. To that end, a summary comment
      will be added to github for further discussion offline before the
      next meeting.


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

  Joey Arhar
  Tab Atkins-Bittner
  David Baron
  Keith Cirkel
  Daniel Clark
  Yehonatan Daniv
  Jon Davis
  Hidde de Vries
  Elika Etemad
  Robert Flack
  Mason Freed
  Chris Harrelson
  Aditya Keerthi
  Roman Komarov
  Una Kravets
  David Leininger
  Olli Pettay
  Jen Simmons
  Alan Stearns
  Lea Verou
  Greg Whitworth

Chair: astearns

Scribe: hdv


Presentation on styleable <select>

  <jarhar> slides:

  emilio: You mentioned having interoperable keyboard behavior… I don't
          mind one way or another, but wonder… behaviours are quite
          different between platforms
  emilio: is having completely standardized keyboard behaviour in
          addition to styling across platforms worth pursuing?
  jarhar: This point hasn't been discussed a lot… the idea of trying to
          converge the behaviours came up at Open UI

  lea: Was the datalist wrapper added because of web compat issues?
  jarhar: Yes

  masonf: emilio, we should definitely talk about the keyboard
          behaviours, it was brought up at Open UI because of
          accessibility issues with having differences between platforms
  <jarhar> issue for html parser changes:

  jensimmons: Can you explain the thinking behind using
              appearance:base-select rather than a generic appearance
  jarhar: Yes, it was one of the points of feedback in the first agenda


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

  jensimmons: Can you explain the thinking behind using
              appearance:base-select rather than a generic appearance
  jarhar: Yes, it was one of the points of feedback in the first agenda
  jarhar: One of the points was that it would have forward compat
          issues, so when we ship the new thing we would break websites
  jarhar: Would be happy to make a bikeshedding issue for this so that
          we can choose a name
  <TabAtkins> Yeah, this was proposed by the csswg in a previous
  jensimmons: Feels like there is a larger conversation that needs to
              happen around the strategy, to make big high level
              decisions, to avoid spaghetti 5 years from now
  <TabAtkins> The forward compat concern is very real
  dbaron: In this case we ended up with base-select because of thinking
          about the future, to try and keep an obstacle out of the way

  florian: I see the forward compat issue with just using `base`… but
           there is also a different problem with using `base-select`,
           what about telling other elements that they are a
  florian: last time we discussed something like that in CSSWG
  florian: I think we talked about it would be useful, but as its own
           value so that it would not be overly generic or specific
  florian: so why should this be a CSS property rather than an
  jarhar: I've started implementing this. Thing is we can't modify DOM
          based on computed style, so I was able to do everything in
  jarhar: Someone on my style theme existed we could have something
          like the light and dark function, but then appearance auto vs
          base, and that seems to work
  jarhar: third point, if we make it appearance base there is forward
          compat issue, and with base-select we avoid that

  emilio: To play devil's advocate re base-select being too specific…
          there are various already existing bits where this happens.
          If we get to the future where all form controls have their
          own appearance:base-something we could in theory introduce
          appearance base
  emilio: so we could see base-select as an in between step
  emilio: I don't feel too bad about the appearance-something approach
  <TabAtkins> Yup, I was gonna say exactly what Emilio is saying here,
              if used in the wrong elements it'll just act like auto
  <una> Agree - we can always limit base-select to select elements
  emilio: Don't think implementing is somewhat tricky to add something
          for each form control but it should be fine
  <jarhar> the -internal-appearance-auto-base() as I've implemented it
           is only for two properties

  florian: I think you made a reasonable on why it is doable to do it
           in CSS, but why is it preferable?
  florian: Regarding that it is already the case for some properties…
           yes, but it goes against the design principles, the
           concluded we needed none and auto and nothing else
  florian: so native mode or non native mode would be what this flips
  florian: Final point of consideration: CSS is primarily used with
           HTML, but not only with HTML, so other languages that are
           not HTML would need to define what these form controls are,
           seems less great if this would only work on HTML
  jarhar: I brought the HTML option to WHATWG, there is pretty strong
          pushback by the editors
  jarhar: it does seem to have nice developer ergonomics and get the
          ability to style it with CSS.
  chrishtr: Another argument was made, since it's really just about the
            styling it would be good to put it in CSS, it's not about
            behaviours, it is about styling
  <TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a
              number of SVG-specific properties already.

  jensimmons: How much does the state switching affect the
              functionality of the form control vs how much does it
              affect styling?
  jarhar: Interoperable keyboard behaviour may be part of this, not
          sure if that is considered functionality
  jensimmons: Sounds like you're thinking that with the change, other
              markup can be put in select, whereas without the change
              that markup doesn't have the same behaviour inside of
  jarhar: The native picker could use markup to try and add stuff
  jarhar: One idea was that you could put images inside of options,
          that still works in the appearance auto mode
  jensimmons: Seems like the sense is, we want to do a lot of things
              with select, so we add the ability to add any HTML… so we
              need some kind of toggle to specify the New Thing is
              being used. But it's unclear then if that New Thing
              introduces new behaviour
  <florian> +1 to jensimmons
  jensimmons: eg what if the CSS doesn't load?
  jensimmons: I am thinking… maybe we don't need a big toggle switch to
              enable the behaviour?
  chrishtr: jarhar did think about these things…the prototype he
            mentioned earlier did implement these things

  masonf: Anne's point seems to be… most of these things are behaviours
          and it would not be safe (from privacy/security pov) to allow
          arbitrary content to pop over
  emilio: Firefox restricts the select area to the top level viewport
          to avoid this kind of spoofing attack
  masonf: Sorry, meant to say in Chromium
  masonf: So the point is that moving between old and new mode with a
          switch in HTML is that it would need to be done piece by
          piece, CSS switch would make that easier

  jensimmons: Are you assuming we should have `base-*` for each
              individual form control?
  jarhar: Yes
  chrishtr: And then in the future we could introduce `base` as a
            shortcut so that authors don't need to worry about it
  <gregwhitworth> yeah, this is akin to flex-gap || grid-gap and gap
                  once it's broadly supported
  chrishtr: We want to avoid people using `base` to get the hot new
            stuff, but then opting in to all the things, including
            things they don't want

  aditya: If we're using an attribute authors would need to specify
          that attribute everywhere in their HTML, would be easier to
          apply it to all your controls with one property
  keithamus: That was one of Anne's points as well
  keithamus: To try and represent Anne's opinions… markup represents
             the data structures, but not necessarily the UI… so if you
             put a button inside of an option would that button's text
             content represent the options content?

  keithamus: To answer jensimmons's question… a lot of the markup stuff
             would be ported as good as we can to 'old' `<select>`…
             `appearance: base-*` would be to turn off all the styling
             but not as aggressively as `none`

  fantasai: To the extent this is about largely styling… to have one
            appearance base I think I agree with florian would be best
            to not do that
  fantasai: It would be nice if we could look into how appearance base
            could work for all form controls, so that we could try and
            ship it as one thing rather than creating all the
            individual ones, which would be more complicated to learn
            for folks
  fantasai: that might require a bit more work, but if we can manage to
            get it to work it would be better to try and do that

  <TabAtkins> Note that this is the same thing we did with reading
              order, for similar reasons
  <TabAtkins> I don't think it's possible, fundamentally, to have
              "base" work while we haven't designed the behavior on
              everything else.
  <TabAtkins> *especially* the moment we start doing the input types.
  <gregwhitworth> +1 TabAtkins

  astearns: I realize we didn't start with 'what we want to get out of
            this', jarhar what would you like out of this for next time?
  <gregwhitworth> +1 astearns
  jarhar: I would like to get agreement that we should use css,
          whatever property or value, to opt in to the new mode instead
          of html
  <masonf> I think redesigning all of the form controls is a bit more
           than "a bit more work".
  <gregwhitworth> +1 masonf

  astearns: Let's have a summary comment in the issue next time so that
            folks can review
  <jensimmons> I really appreciate the history meeting mode –
               especially since much of this work has been done
               previously inside one or two companies. I am glad to be
               able to catch up and hear where the discussion is at now.
  <dbaron> I think one of the underlying issues here is that we have
           CSS discussions that say "X does not belong in CSS" and
           WHATWG discussions that say "Y does not belong in HTML" and
           we need to use some of this meeting sorting out that there
           isn't overlap between X and Y. :-)
  <masonf> Much of the work has been done in the open in OpenUI, not
           within a few companies.

  jensimmons: I do feel it was useful to have a history mode meeting
              this time, and can be more practical next
  chrishtr: +1
  <una> +1
  astearns: We're out of time, but will start scheduling these regularly

Received on Saturday, 18 May 2024 16:21:01 UTC