[CSSWG]OpenUI-WHATWG/HTML-CSSWG Meeting 2024-09-19

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

  - RESOLVED: Add the principles and examples of use to css-forms-1
              (Issue #10866: Define design principles for `appearance:
              base` stylesheet)
  - RESOLVED: Add fantasai and ntim as editors of css-forms-1 (Issue
              #10866)
  - RESOLVED: Do not add a pseudo-element for the user-agent fallback
              select button (Issue #10717: Pseudo-element for select's
              UA button)
  - RESOLVED: Font properties won't be set in the UA style sheet (Issue
              #10857: UA stylesheet for appearance:base `<select>`)

Content Model
-------------

  - There was interest in expanding the PR for WHATWG issue #10317
      (Content model and 'what' to render for stylable <select>
      elements) to capture many more types of elements.

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

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

Present:
  Adam Argyle
  David Baron
  Keith Cirkel
  Emilio Cobos Álvarez
  Elika Etemad
  Chris Harrelson
  Sanket Joshi
  Tim Nguyen
  Olli Pettay
  Jen Simmons
  Alan Stearns

Scribe: chrishtr
Scribe's scribe: keithamus

CSS UI
======

Define design principles for `appearance: base` stylesheet
----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10866

  jensimmons: Design principles are important, guided the HTML5 plan
  jensimmons: The idea behind design principles is to say that we know
              we're going to get into lots of bikeshedding
  jensimmons: When you're having those discussions in areas with lots
              of other things happening, then the group might have lots
              of agreement that was unstated
  jensimmons: In other cases it can be harder. So one good first step
              is to take a step back and talk about high-level
              principles. Which will make it easier and more fun to do
              the details as a second step.
  jensimmons: Once you set high-level decisions (including priorities
              and order of principles), e.g. priority of constituencies
              on the web, that will help also

  jensimmons: Tim and I prepared this draft and thought about it a lot.
              We'd like to hear from the group what you think and were
              you're coming from
  astearns: This sounds like it could become an explainer?
  astearns: A document we can refer to as we go through more detailed
            discussions
  jensimmons: That could be good.

  astearns: Skimmed through the issue and it seems people like these
            principles
  jensimmons: Good UA default styles for form controls. What happens by
              default when appearance: base is set
  jensimmons: which need to be the same in all browsers
  jensimmons: One principle is that appearance: base controls should
              look like the control and be usable
  jensimmons: Should also pass 100% of WCAG AAA standards
  jensimmons: AA instead might be the minimum instead though, since
              very high contrast is difficult
  jensimmons: Styling should be consistent across controls
  jensimmons: e.g. today appearance: auto mode is not just different
              across browsers, but even across controls on the same
              browser
  jensimmons: Example: borders should look the same thematically, and
              also use similar syntax e.g. hex numbers
  jensimmons: should be easy to adjust to a site's preferred styles
              without a hard-reset style sheet
  jensimmons: We discussed this one a lot internally to webkit, because
              it could be hard to achieve this
  jensimmons: It should not be surprising to developers why things
              happen when they try to restyle
  jensimmons: Should be as simple and direct as possible
  jensimmons: Developers will be mixing their overrides with UA styles,
              and that should be straightforward
  jensimmons: Maybe "wireframes" is a good word to capture this
  jensimmons: Font styles for example. Should a for set one? I think
              likely it should just inherit the document font
  jensimmons: Therefore inheriting existing styles as much as possible
              is best
  jensimmons: Simplicity is also a goal - avoid drop shadows or other
              extra effects when possible

  fantasai: pseudo-elements are another thing. Hacking up `::before` is
            not good because it makes it harder for developers to use
            that pseudo-element for their own purpose
  jensimmons: I can see authors seeing an "align" rule, and then
              secretly find it in the `::before`. avoid confusing stuff
              like that
  jensimmons: Should fit into context well. For example, a form control
              set as a child of a grid should participate correctly in
              the grid
  jensimmons: Should be comprehensive. Form controls may look simple on
              the outside but are complex inside. e.g. focus, disabled
              state, writing modes, OS modes, should all work.

  dbaron: I like this list of principles
  dbaron: At the same time, I think some of the interesting dates are
          about cases where the principles disagree with each other.
          For example, if I want to really reduce them, principle 5
          says "less styles". Whereas 2 and 6 kind of say "more
          styles". Balancing them could be tricky.
  dbaron: Writing down these principles is valuable, but working
          through examples will help us to figure out the right balance.
  astearns: I also like these principles. Thinking about it
            organizationally, what should happen where is no additional
            styling is one, and another is what happens when the author
            adds in styling. So 4.2 should be in 5?
  astearns: May be 5.2 and 3 should be in 4?
  astearns: These are just editorial tweaks not really changes to the
            principles

  keithamus: Contrary to David's comments, I think it's ok that they
             may appear contradictory. But it helps to keep us on track.
  keithamus: e.g. border-radius may not be needed because it's not
             necessary
  <dbaron> (I don't think it's bad that they're contradictory; I just
           think we need to recognize that they are.)
  keithamus: For example, the UK government style guide may not look
             great by default but is quite usable and accessible
  keithamus: The OpenUI group has done a good job at looking at the
             intersection of all design systems. We should utilize that
             research to guide choices made here.

  astearns: Responding to one thing you said Keith: agree that not
            everyone should agree the base styles are beautiful, but
            I'd like something about it to be good looking and not just
            purely utilitarian
  keithamus: Agree with some of that. We can't just take one design
             system. In fact I do think the UK gov design system is
             quite beautiful in its simplicity and utility.
  jensimmons: Maybe we should add "be beautiful when possible?" to the
              design styles?
  jensimmons: Agree that the design constraints contradict each other.
              e.g., border-radius does help some of the principles
              ("recognizable") but may interfere with others
              ("minimal").
  jensimmons: Drop shadow may have similar tradeoffs, but land on the
              other side -- no we need box-shadow to be usable

  keithamus: One thing I forgot to mention, we can also use these
             guidelines to look at the complexity of the UA style
             sheet. WCAG requires minimum sizing. Sites often change it
             based on media queries. But our guidelines could move us
             away from depending on media queries.
  keitihamus: Think we should consider a guideline to avoid media
              queries in the interest of simplicity and predictability
  jensimmons: Agree we should avoid those, but maybe we don't need to
              mention it specifically in the principles

  dbaron: A related point is that I think being easy to override
          depends a lot on what we're doing. If it's a border radius or
          box shadow, developers can probably figure out how to remove
          them. Where it's harder to override are less obvious cases,
          like media queries or states (if the control have states with
          default styles, developers might not notice all of them and
          forget some)
  dbaron: Some of the aspects of easy-to-override are about
          interactions and complexity more than base styles like
          border-radius or shadows
  jensimmons: That's really important. Maybe we need to add to this
              list or maybe it fits into principle 5
  jensimmons: We need to make sure that the specificity is such that
              when they override they don't accidentally miss corner
              cases due to states
  jensimmons: This starts to pair into work that Tim is doing to define
              pseudo elements
  jenseimmons: If things are getting complicated maybe we need to
               define a new pseudo element to simplify

  keithamus: Don't know if this is going to grow scope, but: if we
             introduce colors, we should name them
  keithamus: Introduce new color keywords for these? Tokenizing/
             variables, so that design systems can change them across
             the board
  astearns: From a CSSWG perspective then systematic overrides are a
            good use case that justifies keywords
  ntim: There is going to be a TPAC breakout session on form control
        defaults, please join!

  <fantasai> https://drafts.csswg.org/css-forms-1/
  fantasai: There is, in the CSSWG repo, a document with ideas at
            css-forms-1. We could take over that document and put these
            principles there.
  ntim: We have started a draft of a css forms spec internally to
        webkit, and hope to bring that to the group
  fantasai: We can start with design principles and then add pseudo
            elements and so on later
  astearns: I assume we'd also have examples there to highlight the
            tradeoffs? or the media query example
  astearns: anti-patterns listed would be useful also
  <chrishtr> +1 to css-forms-1

  RESOLVED: add the principles and examples of use to css-forms-1
  RESOLVED: add fantasai and ntim as editors of css-forms-1

Pseudo-element for select's UA button
-------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10717

  jarhar: I finished implementing the removal of the buttons and
          replacing with div w/text in Chromium. Then fonts are
          inherited well. So I think it works well.
  jarhar: Propose not to create a pseudo-element for the select button
  <fantasai> +1
  <ntim> +1

  RESOLVED: do not add a pseudo-element for the user-agent fallback
            select button

UA stylesheet for appearance:base `<select>`
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/10857

  jarhar: There has been good discussion in the issue, and I've created
          two sub-issues for some topics
  jarhar: Don't know if there is anything specific to resolve in the
          issue right now?
  fantasai: We could resolve to inherit the font?
  <dbaron> yeah, +1 to inheriting the font
  ntim: Think it could be good to delay this discussion to after or
        during TPAC
  fantasai: Agree in general
  fantasai: Also for all form controls and not just select
  jensimmons: Would be best to discuss then/later
  jarhar: I'd like to discuss things like which pseudo elements we
          should add, how to specify colors, ...
  fantasai: Let's reschedule so that the breakout agenda is rescheduled
            into the OpenUI joint meeting?
  astearns: We could have tentative discussions at the breakout and
            then finalize them at the group later
  <sanketj> https://github.com/whatwg/meta/issues/326

  chrishtr: While we do want consistent styles, `<select>` is being
            worked on this year and we need to ensure we don't
            unreasonably delay decisions based on that.
  chrishtr: We can use it as a place to set precedent for the others
  astearns: So here is the precedent, but if we make a mistake we can
            change them as we integrate into the larger set?
  chrishtr: Sure we can make changes later.
  <ntim> I'm hoping that TPAC gives enough time to resolve most things
         regarding UA stylesheets! My goal is more to help drive
         select's direction not block its progress :)
  <ntim> (or not setting the font at all)
  <jarhar> +1 to using unset for font properties

  RESOLVED: Font properties won't be set in the UA style sheet

Content Model
=============

Content model and 'what' to render for stylable <select> elements
-----------------------------------------------------------------
  github: https://github.com/whatwg/html/issues/10317

  jarhar: This issue was created because accessibility experts are
          concerned about authors ending up with inaccessible structures
  jarhar: We should discuss which are allowed so as to preserve
          accessibility. I worked with accessibility experts from
          OpenUI and came up with a list of elements which should be
          allowed within select: divs, spans, img, text within options
          but outside
  jarhar: and legend elements as child of optgroup to replace label
  jarhar: this has the same a11y mapping but is more styleable
  jarhar: My HTML spec PR is ready to go so from my perspective it's
          ready. Should we go with this approach?
  <astearns> pr: https://github.com/whatwg/html/pull/10586

  emilio: Curious if we're going to have special rendering for legend
          like we have for fieldset, or are there any other special
          rendering rules?
  emilio: If you put a legend into a fieldset the the rendering is
          quite special. The first thing gets moved up to the top
          regardless of where it is in the DOM, and other layout tree
          reparenting.
  emilio: Hoping we don't have to do any of that
  jarhar: My preference is also not to do anything special. didn't come
          across any need to have special rendering in prototyping in
          Chromium. I just set up the a11y mappings and changed the
          rendering of the optgroup element so it would stop rendering
          the label attribute part when there is a legend child

  fantasai: On the PR: it says div and span, but not various other
            elements like em or bdo. Why not?
  jensimmons: There are so many other elements that seem reasonable?
  fantasai: Ruby also
  jarhar: These are good points and should be included within option
          elements. These rules are about content outside option
          elements.
  jarhar: Maybe we can use a more broad rule for inside-option parts
  fantasai: Span or other inline elements don't belong outside option
  fantasai: Div allowed but not span because span is inline

  astearns: Are there tests?
  jarhar: The tests for the content model: not sure how to do that. In
          the Chromium implementation, we render everything but use
          developer tooling to guide people towards accessible
          outcomes. tl;dr I don't know how to test it in WPT.

Received on Saturday, 21 September 2024 16:43:15 UTC