- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 26 Jul 2024 16:27:58 -0400
- To: www-style@w3.org, public-open-ui@w3.org, pastithas@google.com
=========================================
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:30 UTC