[CSSWG] OpenUI-WHATWG/HTML-CSSWG Meeting 2024-07-25

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

How to implement and shape API for `<selectedoption>` element for
    `<select>`
-----------------------------------------------------------------

  - RESOLVED: Move forward with the light dom cloning API shape and
              discuss timing in the issue

Popover Topics
--------------

  - There was strong use cases to support the need to solve especially
      for the tooltip case, though also acknowledging this will be
      challenging on touch interfaces.
  - Several people clarified that, though we've been just saying
      tooltip, they had both a rich and a basic tooltip in mind that
      would have somewhat different behaviors/needs.
  - Concerns were also raised if this was the right ux to expose
      information. Some folks believed it was, but others will have
      conversations with design teams to form an opinion.
  - Discussion will resume in a few weeks after folks have had a chance
      to think more with their internal teams.

Issue #10462: css-ui- Pseudo-elements for stylable select
-------------------------------------------

  - There was a brief introduction to the proposal to have pseudo
      elements to target the fallback element and the concern that we
      need to use something that doesn't expose the shadow parts.
  - Time ran out before the group could discuss further so conversation
      will continue on the issue.

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

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

Present:
  Joey Arhar
  David Baron
  Keith Cirkel
  Daniel Clark
  Emilio Cobos Álvarez
  Brecht De Ruyte
  Mason Freed
  Chris Harrelson
  Sanket Joshi
  Aditya Keerthi
  Olli Pettay
  Alan Stearns
  Greg Whitworth

Scribe: gregwhitworth

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

How to implement and shape API for `<selectedoption>` element for
    `<select>`
=================================================================
  github: https://github.com/w3c/csswg-drafts/issues/10242

  jarhar: There was a CSS issue where we briefly discussed this and the
          usecase is that if you are making a customizable select
          element you want to have a button that is fully styleable and
          contains rich content within the button and style it
          differently than the content that is in the option
  jarhar: If you have a country picker and the option only has the flag
          representation but in the selectedoption shows the other DOM
          content within it. When the option is changed the contents of
          the option itself will be changed with the selected option's
          DOM content
  jarhar: The way I've implemented this in the Chromium POC is to use
          the cloneNode API and it works pretty well
  jarhar: In the past we've discussed using a useragent shadow and the
          sanitizer API
  jarhar: This would require us to complete the sanitizer API and a new
          CSS syntax

  emilio: What is the behavior if you don't have <selectedoption>
          element?
  jarhar: If you don't provide a button at all then you'll get the same
          behavior you get today where the text content is copied into
          the button. If you provide the button without the
          selectedoption element then it won't be copied
  emilio: My only concern was if you were going to change the shadow
          DOM. It feels kind of clunky to change the Light DOM and all
          of its benefits but I don't have a better proposal

  smaug: I think the light DOM option might be fine. This is similar to
         SVG use
  smaug: In Gecko it re-clones when we do style flush so you kind of
         want something like that here and since Anne was asking about
         scheduling
  emilio: Do we want to handle dynamic mutations to the selectedoption
  jarhar: We want to keep up with any mutations on the element itself
          which Chromium uses today
  jarhar: The mutation observer will catch the mutation and clone the
          content into the shadowRoot of the button
  emilio: The key tricky bit is when this should run
  emilio: It should be similar to mutation and changeEvent case
  emilio: if we use mutation observer timing
  smaug: It would be odd that it wouldn't get the correct layout
         information
  emilio: In Gecko we have internal mutation observers that happens
          synchronously
  smaug: Whenever layout is flushed we do the actual clone
  emilio: It is odd to do DOM observable changes at style flush time
  emilio: I don't think that would be a viable option here
  smaug: If you're updating Light DOM all of the other observers will
         still work so they should work as expected
  emilio: If you modify the option and read back the bounding client
          rect you should have the same issue
  chrishtr: If someone were to polyfill this with mutation observers
            they would get the experience?
  emilio: In jarhar's example you grow the size of the icon or
          something upon cloning and you get bounding rect on the
          element you would need to wait for the post microtask

  astearns: Do we need to have more discussions about timing in the
            issue or can we resolve it?
  emilio: I think we should discuss it async as there are tradeoffs
  chrishtr: Is it ok to conclude that the approach we're taking is ok
            but we need to resolve on the timing?
  emilio: I suppose so, but if the timing is not right then it may make
          it so then it may require us re-thinking the light DOM cloning
  chrishtr: What considerations would make it "not fine"?
  smaug: In theory we could use custom element reaction timing which is
         sooner. We have options but haven't gone over them
  astearns: Let's set timing aside for a minute

  dandclark: I added myself to the queue to support the light DOM
             solution since it's all author controlled content
  dandclark: I would like to be able to explain the timing with author
             defined APIs and it will be easier to understand
  dandclark: We can discuss that more in the issued
  <chrishtr> +1 to microtask timing
  emilio: Custom element reaction timing seems worth exploring and
          would make things more consistent
  emilio: It is an issue beyond layout but any type of DOM interrogation
  astearns: We can resolve that we want to move forward with this shape
            but discuss the timing more

  astearns: Any other concerns?
  <emilio> +1 to light dom if there is a reasonable timing for it
  <jarhar> proposed resolution: move forward with the light dom cloning
           api shape and discuss timing in the issue
  <masonf> +1
  <gregwhitworth> +1

  RESOLVED: Move forward with the light dom cloning api shape and
            discuss timing in the issue

  smaug: Anne was asking about the solution for multiple
  astearns: and maybe a separate issue

Popover Topics
--------------
  github issues:
      https://github.com/whatwg/html/issues/9625
      https://github.com/whatwg/html/pull/9841
      https://github.com/whatwg/html/pull/9778
  scribe: jarhar

  masonf: Chrome is working on enabling the tooltip use case. There are
          a number of tooltips on the web, every design system has one.
          We are working on a set of apis that enable that use case,
          and I wanted to talk generally. Those things are popover=hint
          and a proposal called interesttarget. interesttarget builds
          on the invoker commands api.
  masonf: On the standards position for popover=hint webkit said they
          were leaning negative and it sounded more generally negative
          about tooltips. Maybe it would be good to agree on the use
          case itself and maybe get into a little bit of the detail.
          Does that make sense to do today?
  masonf: One thing I think I've done poorly here is pushing for the
          apis separately and no collective talk on how they're
          important with each other
  masonf: Web platform has one primitive for tooltips which is the
          title attribute. There are a number of problems with that
          api. html spec has a note that says please don't use this
          thing. It only supports plain text, it doesn't work for all
          users, no support for keyboard users, touch isn't great, etc.
  masonf: Developers complain about lack of customizability
  masonf: State of the web is to go build your own tooltip. When things
          are re-invented there are bugs and problems, and there are
          accessibility problems
  masonf: lack of support for touch users, keyboard users, and
          assistive tech users
  <astearns> webkit discussion:
https://github.com/WebKit/standards-positions/issues/305#issuecomment-2250443326

  masonf: This is more general than tooltips, but that's what we want
          to make sure we solve
  masonf: We want to hover an element or something else and make sure
          that opens a tooltip. This could also be used for menus,
          hover over a menu and a submenu appears
  masonf: Solution we're aiming for currently are two apis. The popover
          api gives a lot of functionality that we need, but there's an
          interaction problem. Typically tooltips - when they show up
          they don't close pickers that are open. If I have a select
          element that's open and I hover something else, the tooltip
          doesn't close the picker. That's a slight tweak to the
          behavior of popover, so we have popover=hint
  masonf: The other thing we need for tooltips is activation. Typically
          you want to show a tooltip when you hover over an element or
          keyboard focus it or touch activate it, and that's what we
          call the interesttarget api. That one is more difficult and
          is more broken in the title attribute in browsers today, but
          that's a problem that needs to be solved
  masonf: We have modeled that on another api called the invoker
          commands api, which is more general which has a button that
          activates an element like a popover or dialog
  masonf: There is one element that is triggering an activity on
          another element, keyboard activation is similar to that.
          That's why all three apis are grouped together.

  masonf: General question I have: Do people think tooltips is a thing
          we should solve? I want to get to stage 1 in whatwg where we
          can say this is a problem worth solving. pushback so far has
          been maybe not.

  keithamus: I want to give more motivation why we should solve this. I
             do represent github. The problem that we face for tooltips
             is lack of discoverability. The title attribute is not
             wcag aa compliant. Technically there's a carve out for
             that, so we need to craft our own tooltips. Profile
             summaries and issue summaries as well. There's a good
             business case and usability cases for that. There's a
             serious problem with the lack of discoverability for a11y
             users.
  keithamus: Hard to find good discoverability without being too
             verbose. We talk to them and we say that you can press
             this button to traverse into hover cards. Then we announce
             on traversal and they say that's too much. These are
             difficult to have in userland because we don't have the
             facilities with aria and announcements for that. Separate
             topic, aria notify. But do we need to continually ship
             these low level primitive, or can we say that this is a
             bigger thing that we need to solve
  <chrishtr> +1 to strong use cases
  <brecht_dr> +1 on that

  sanketj: I want to +1 that. The use case and developer need is there
           for tooltips. I do understand that this is more challenging
           on touch and we need to figure out something. My question
           for the group is, is there a way to separate the discussion
           of is tooltip a useful concept vs what is the activation
           story for touch surfaces?
  masonf: That's what I'm going for here. The discussion has been
          muddled because of the mixed questions of how do you do touch
          and is this worth solving. I want to do the is this worth
          solving question first
  sanketj: Makes sense to me. Tooltip is an important problem, no
           question

  akeerthi: Main concern is portability on other platforms. Until we
            get that, not sure that tooltip is the right ux. We still
            need more investigation on our side to consider alternative
            ux before mandating that tooltips are the right path forward
  masonf: You said main concern is portability to other platforms, like
          touch. But it sounds like that is the reason that you're not
          sure that tooltip is the right use case to solve
  akeerthi: Yes tooltip as a pattern itself. Websites are using them to
            expose useful information, but we're not sure that tooltip
            is the right ux pattern to expose that information.

  smaug: Is this a hint or tooltip? I think the feeling was that this
         is a hint and we're not actually trying to implement tooltips.
         I get confused here. The github use cases are not traditional
         tooltips but they are something a bit different
  keithamus: Two problems that need solving. One of them is stylable
             tooltips, which we implement our own because we want
             control over styling and timing. I know there's work to
             look at stylable tooltip but we still need to control
             timing and interactivity. We want modes where when one
             tooltip is open then it has reduced timing to open other
             tooltips so you don't have to wait 2 seconds each time
  keithamus: Second case for rich tooltips as I call them, but we call
             them hover cards at github. I think the same - they're
             conceptually very similar. We want the same delays, same
             patterns. We could use popover to implement both of them.
             If were going to look at stylable titles, then there's a
             lot of work there to expand it to the level of
             capabilities that a site like github expects. There's two
             use cases if you want to separate them.
  masonf: I've been calling them both tooltip, one is plain and one is
          rich. Various names, but I've been trying to group them and
          solve them both
  masonf: If narrowing that down changes the view of webkit that would
          be important to talk about. It's only triggering that is the
          concern and that would be the same for both
  keithamus: For a plain tooltip, its generally going to be auxiliary
             plain text information, like a description for a button.
             We can solve those in an accessibility forward way by
             setting aria label on a button. They could be solved
             differently. On a touch device, you could long press
             inside the button. Because it's plain text there's a lot
             more affordances. For a rich tooltip we want tighter
             control, a hover card has interactive stuff in it
  keithamus: The point there is that for an a11y users they don't need
             to traverse into a plain tooltip, they need to have it
             announced. It's just a mini page that's on top of the
             other ui
  masonf: I believe the objection is about triggering and not a11y. For
          a keyboard or mouse user you still have to trigger it
          somehow. The triggering story is the same in either case
          right?
  keithamus: For the a11y case its not necessarily. But largely I agree
             and that is desired. We want a uniform ui for different
             surfaces, like touch and desktop. There's no way to
             cleanly delineate those because of a laptop with a touch
             screen
  keithamus: You can also plug a mouse into an iphone, so who knows
             what to do

  chrishtr: It sounds like we made some progress. Perhaps we should use
            the terminology tooltip for the text based explanation of
            what a menu or button is going to do, which I think is what
            Keith was saying. Hover card use case, is like a rich
            information dialog or a preview of a page that you would go
            to if you would click but you don't want to click on it
            because its slower or worse ux
  chrishtr: Title or aria can work for first use case, for the hover
            card case, maybe this has different requirements to it. Is
            it really necessary to expose hover cards? Is it a
            convenience as opposed to a necessary part of users
            understanding the ui? If its a addon that's nice to have
            for mouse users, then it's not really necessary for users
            to understand the page. For a touch only device, exposing
            it through a special gesture or menu provided by the ua
            that's not as discoverable is ok because its not actually
            needed to understand the page
  keithamus: The way we architect hover cards is that a lot of the
             information is preloaded vs the entire user page. It
             offers us a way to alleviate compute pressure which is
             easier on our servers. The big one there is that if we are
             able to preload the information in hovercards, for users
             on mobile who don't have stable internet, that still
             requires a request at the time of press for a full page
             preview
  keithamus: To the aria label case, I think again if we can make title
             as capable as most design systems, which means stylable
             and controllable delays it could be a good happy medium
             but by the time we get there we would be implementing what
             we already are proposing with interest targets
  chrishtr: What you said seems to correlate with what I was proposing
            for how to think about it. It optimizes for developer and
            user but its not necessary to understand the page
  <ntim> There's already a ::tooltip pseudo-element suggested in the
         CSSWG to style the `title` attribute popup
  keithamus: I agree that its not necessary. I was hoping for it to be
             a better ux for mobile users. If you're on a desktop
             machine the latency is better and you might not need it as
             much as mobile
  masonf: I think we all agree that tooltips are auxiliary information
          to understand the page, but it doesn't mean that people
          shouldn't be able to get them. But there should be a way for
          every user to access them

  gregwhitworth: I would love to understand, you mentioned Aditya that
                 it was the input modalities that you would need more
                 investigation. Do you know when that would be?
  gregwhitworth: Our paradigms are all the same, put some content in
                 the popup. It would be unfortunate to spend time and
                 just say no again
  akeerthi: In 2 weeks we can follow up with our design team
  ntim: We want to solve for all our platforms: ios, vision os. vision
        os has specific challenges, privacy.
  gregwhitworth: Other companies have devices that have popups on top
                 of them. I would love if we're going to push back from
                 a ux perspective can we push back instead of just say
                 we don't like the ux
  gregwhitworth: If they're not uniform at a platform level than ATs
                 won't work
  gregwhitworth: The user has low vision so even though they're on a
                 desktop they'll have it zoomed in so a lower-case P
                 fills the laptop screen. So a "desktop" experience is
                 equivalent to a mobile physical visual experience
                 (maybe even smaller) perspective
  gregwhitworth: Solving this in the platform is invaluable so I don't
                 think we should delay it
  gregwhitworth: Especially if y'all have ideas on how to solve the a11y

  chrishtr: Keith I'm wondering if github has any touch based ui that
            you've experimented with for hover cards that we could use
            for inspiration
  keithamus: We haven't done anything with it because its quite
             restricted. The idea is that it would be a long press but
             you don't get the same part of the access or you disable
             things that people do want like open in a new tab, so we
             just don't have them on mobile. But we would like to have
             them on mobile. We are limited in userland to do this stuff
  chrishtr: So you would like to do long press but you can't?
  keithamus: We could emulate a long press itself but then we would
             prevent native menus, and native menus we can't emulate,
             or we could try but it would be undesirable. It's a
             problem that needs a large amount of investment if we're
             going to do that. I don't see a great payoff and its hard
             to make a case - let's investigate for 6 months but
             hopefully we can talk here instead
  chrishtr: If the long press opened the context menu but there was
            something in there that said open hover card would that be
            a good ux?
  keithamus: I think that would be acceptable, yeah.
  keithamus: I looked at how we could do content negotiation sniffing
             for showing the preview card. We looked at that but the
             problem is that there's no interactivity. We have very
             limited options. I think a menu option would be an
             acceptable tradeoff on our side

  astearns: On the issue of better styling for title content, there is
            a proposal that Tim noted for a tooltip pseudo for that
            kind of styling
  masonf: That would allow you to just change one thing about one set
          of content, not have text in two different fonts etc
  astearns: We will continue the discussion of invoking these things
            and talk about the use cases generally once people get back

  astearns: Anything more we should talk about these today?
  masonf: I thought about talking about popover=hint specifically, is
          unrelated entirely about triggering since it's just about
          other popovers
  masonf: Could be used to build hover cards if you build triggering.
          I'm wondering if there's appetite to have support for
          popover=hint and that way we can focus on the hard part
  astearns: Intent would be to approve on popover=hint changes?
  masonf: Yes
  akeerthi: I'd like to hear from Anne on this, I think it would be
            reasonable to wait
  masonf: There's a recent comment on webkit standards for that
          proposal. Sounds like we'll wait again to discuss this in a
          couple weeks

CSS UI
======

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

  jarhar: We spoke about the shadowroot structure of the select element
          and we want to target them with the pseudo selects
  jarhar: This is a proposal to use pseudo elements to target the
          fallback element or one that is supplied by the author
  jarhar: I spoke with emilio about this before and it can target both
          author and shadow and CSS you can target the same element
          there was concern
  jarhar: You can target them as pseudo elements and regular elements
  jarhar: Make it so that the pseudo elements don't target the author
          elements
  emilio: There are a fair amount of APIs that will need to cope with
          this and not make it really complicated and we'll get it
          wrong and things will be inconsistent

  emilio: Let's start with nothing too special or an alternative like
          animations don't expose nodes that are shadow parts
  emilio: We ideally would be able to solve that but if you're
          observing it from the outside it's a part, if you're in the
          tree you observe it like normal. We can do something like that
  emilio: We have a resolution to do more part() type pseudos and make
          them behave like shadow parts
  emilio: We don't expose a reference to them like other elements and
          then we can kick down the road to expose them in these APIs.
          Which honestly I've never seen anyone complain about that and
          you can put the datalist in the light tree if you want
  emilio: I haven't thought through all of the implications and I don't
          think we have a definition of this part "like" element for
          this
  emilio: Effectively we won't hit that kind of problem

Received on Friday, 26 July 2024 20:28:32 UTC