- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 15 Aug 2024 19:42:37 -0400
- To: www-style@w3.org
=========================================
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 Values 5
------------
- RESOLVED: 1 more calc-size edit in, then issue first working draft
of css-values-5
CSS Easing 2
------------
- RESOLVED: Add ChrisL and TabAtkins for easing level 2 and publish
FWD (Issue #10688: Time for FPWD)
Add hover/focus/long-press triggering delays to CSS
---------------------------------------------------
- There was a lot of discussion and thought about if tooltips are
worth solving in issue #9236. There wasn't a clear yes or no
decided on the call, however a lot of good points were raised
that needed further discussion. Some of the questions/comments
were:
- Specific delays might be better than named values
- Different delays based on modality, hover vs touch
- If focus delay should be zero or if tabbing should have a
different behavior
- Should there be a pseudo class for first tooltip open
Selectors
---------
- RESOLVED: Edit in what's described in Tab's last comment:
https://github.com/w3c/csswg-drafts/issues/10179#issuecomment-2093869789
(Issue #10179: Should :not(foo) match the host of the
shadow tree?)
- RESOLVED: :host:has() can match, :has() can't (Issue #10693: Should
`:host:has()` match?)
====== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0008.html
Present:
Rachel Andrew
Adam Argyle
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Paul Grenier
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Sebastian Zartner
Chair: astearns
Scribe: keithamus
CSS Values 5
============
github: https://github.com/w3c/csswg-drafts/issues/6900
astearns: Any changes people would like to make to the agenda?
fantasai: First public WD of css-values-5?
<fantasai> https://drafts.csswg.org/css-values-5/
astearns: let's start with that
fantasai: Tab and I were thinking we should move values and units
level 5 to FWD. It has a bunch of a features we're all
actively working on
fantasai: we should publish and tweak it, refine issues before we get
to far along
astearns: What features?
fantasai: progress, cross fade, toggle attr, fade, random,
random-item, sibling-count, sibling-index,
interpolate-size...
astearns: Any concerns, those who want more time?
dbaron: I'm supportive. One other edit for calc-size that I was
hoping to make today. I think it's fine but I'd like to make
the edit first
fantasai: We can do that. Let's keep iterating from there.
ChrisL: It takes a few days. It'll be Friday at the earliest.
PROPOSED RESOLUTION: 1 more calc-size edit in, then issue first
working draft of css-values-5
RESOLVED: 1 more calc-size edit in, then issue first working draft of
css-values-5
CSS Easing
==========
Time for FPWD
-------------
github: https://github.com/w3c/csswg-drafts/issues/10688
<TabAtkins> definitely +1 to easing-2 FPWD
ChrisL: This only adds 1 new feature: multipoint linear easing
function. This is already widely implemented.
ChrisL: Proposal to add to Pre-CR exceptions. Which is awkward if its
not FWD
ChrisL: I added WPT annotation so we can see how much is implemented.
but it's in good shape
fantasai: Should we add another editor?
TabAtkins: I've already been doing some edits so happy to add to my
pile
ChrisL: I would but I've got many things, not as much as Tab
fantasai: Maybe we add both?
ChrisL: Fine
PROPOSED RESOLUTION: Add ChrisL and TabAtkins for easing level 2 and
publish FWD
RESOLVED: Add ChrisL and TabAtkins for easing level 2 and publish FWD
Add hover/focus/long-press triggering delays to CSS
===================================================
github: https://github.com/w3c/csswg-drafts/issues/9236
masonf: Quick intro. Recent comments makes me think we need to raise
the issue generally on if tooltips are worth solving. This
issue is around discussing ideas.
<masonf> - Explainer:
https://open-ui.org/components/interest-invokers.explainer
masonf: related to interest target proposal
masonf: General story: other API called command/commandfor/invokers.
Lets you invoke an element based on activating a button. This
API is similar but instead of activating it invokes by merely
showing interest; e.g. hovering mouse, focus keyboard, long
press on touch, etc.
masonf: Use cases are tooltips, hovering menus, other cases where the
user hasn't yet clicked
masonf: I don't think we want to debate the case just yet but we want
to discuss the delays involved in this
masonf: Tooltips are typically implemented with delays to avoid very
noisy UI. That counts as showing interest. The fact the user,
for e.g., has stopped the mouse there for a period of time
indicates to the UA the user showing interest
masonf: Why in CSS? The delays aren't necessarily semantic, but also
are likely applied unilaterally on the page, so perhaps `*`
or some other selector. Also prefers-* queries may influence
that, e.g. reduced-motion.
masonf: Some users may prefer longer delays, its also a developer
specified period of time, some sites - e.g. games - might
want shorter or longer time
masonf: There are two things, one is showing interest, the other is
_losing_ interest, when you move away and want it to hide
masonf: Where it currently stands is a single property shorthand with
two delays, and values are generic, e.g. short/medium/long.
This allows varying by OS or modality, e.g. short might be
shorter for keyboard than mouse
masonf: So. Does this belong in CSS? Or should it be elsewhere? Does
the approach make sense? Are there better ideas? Most
interested in the last.
<TabAtkins> I think this sounds reasonable and I'd like to explore
it. Unsure if this is the exact shape, but this space
seems useful to me.
flackr: As you were talking; one thing that I kept thinking of;
should developers be customizing the delay at all? Original
use case for delay is that hover shouldn't be instant. But if
we don't allow for customizing we can align to platform delay
lengths
flackr: Hover menus aren't a good UX pattern... Is this something
which needs to be customized or is this something which we
can have as a UA value
masonf: I believe there are different use cases eg menu vs tooltip,
tooltip might have a longer delay because you want to make
sure the user wants to see that thing whereas menus might be
snappy
masonf: There is already `title` attribute which users complain is
too long
flackr: We should change that if the common feedback is the delay is
too long
masonf: I don't disagree
astearns: Different timing for different affordances could be
something in HTML. Different built-in timings for that.
astearns: Would we need a `never` or some other value that stays
shown until you hover over the next one?
astearns: Other question; does this belong in CSS or HTML... maybe
this is just a javascript feature? In JS you can determine
MQ state and change things so it wouldn't necessarily be in
CSS
<TabAtkins> I can definitely say that debouncing correctly is much
harder than one would think.
<TabAtkins> (I'm doing that in JS for Bikeshed.)
masonf: The reason I don't think it should be in JS is it's tricky,
debouncing gets interesting, keeping track of various
timings. BTW losing interest can happen from both the button
and the thing that invoked it, so it can get tricky in JS
emilio: This seems doable already in a sense. The same way people are
adding entry/exit animations in dialog. Other than that I
think the feature without a hardcoded duration makes sense.
In theory UAs or something else should invoke this... ???
like invokers. I wanted to clarify that this seems doable
with transition behavior discrete and existing infra, but
maybe that's wrong?
masonf: It's more tricky to do with entry/exit and some things are
impossible like losing interest - you lose interest on the
combination of losing interest on both button and invoker
emilio: The way I think with :hover and transition, keeps the
interest, only if the thing you're popping up is inside of
the dom of the anchor... it's a bit tricky and harder, but
not impossible
masonf: You mention hover, that covers mouse users, but not other
input users. Like popover, it sounds simple for one modality
but gets complex in the details, that's my concern
<emilio> masonf: a counterpoint for that would be that you might be
interested only in one kind of interest (like hover, but not
keyboard focus perhaps?)
<emilio> But yeah the general thing seems worth exploring
PaulG: Always a fan of progressive enhancement. I worry about lack of
consensus on tooltip as a pattern, but just to clarify other
patterns I've seen or used, aside from tooltip... hover menus
are a thing. Focus works the same way, focus/hover should do
the same thing. Touch is the same as a click... my main area
to push back on is timing as a token as a specific time
PaulG: A lot of people are concerned with specific times, especially
wrt satisfying success criteria.
PaulG: so I'd say go towards focus/hover pseudos as a way to separate
those out rather than token/values. Touch would be separate
PaulG: unless we add another pseudo but I don't think it would make a
difference
PaulG: Everything else seems to be answered by the writeup but I'd
like to see other use cases. What seems to far afield?
kizu: Authors need a way to provide custom duration, in my example
let's say a design system already implements this - they
already have different values, we have specific values for
this. If we introduce this through CSS we'd probably want to
match these. We will not have a different experience, users are
used to a certain delay. In this case we'd want to use a custom
property in CSS and normalize for every use case. Kind of
related to what PaulG says, we'd want some way to separate and
where we'd want to apply this.
kizu: Usually we don't want any delay with focus, immediate feedback.
Reason for delay on hover is you can accidentally trigger, e.g.
leave an area, return the cursor the tooltip wants to go away.
With focus this isn't an issue. RIght now this can be
implemented with transitions, but currently not possible with
display transition. When transition to none elements lose
events, so you cannot have transition on display.
kizu: So I agree we need this property but it should be more author
configurable
kizu: e.g. games might want immediate responses.
kbabbitt: I wanted to make the exact same point on games wanting
instant response or 0s or something. AIUI the keywords were
introduced to give a degree of control, that's an important
use case. I wonder if we could do something similar to e.g.
forced-colors where we want to force a UA setting to
override what the author sets.
keithamus: One use case I want to represent, where CSS feels
appropriate
keithamus: delay might want to be configurable based on presence of
an active tooltip
keithamus: e.g. if you currently are looking at a tooltip, and are in
a mystery menu
keithamus: you might want the delay to be shortened on subsequent
things
keithamus: that is trivially expressible in CSS right now, but much
harder in other languages
<kizu> +1 to Keith, libs like Tippy have this as an option:
https://atomiks.github.io/tippyjs/v6/addons/#singleton
ydaniv: Agree with Keith and Roman. Anywhere we try to solve in
keywords, it always failed.
ydaniv: For example in smooth scrolling, left up to UA, and we tried
to migrate to it but it looks different in different browsers
so got lots of backlash from users
ydaniv: I think here it would be good to go with time values. CSS is
a good place to put it. We have all the ergonomics. The right
declarative place to put it.
emilio: I wanted to provide a counter point to the keyword. For more
user-choice vs author-choice, e.g. scrollbar with has auto vs
precise pixel value, otherwise you cannot allow users who
need more delay to have more delay. So I disagree on the need
for precise time.
astearns: One reason we don't have pixel values for scrollbars is
because some OSes don't support changing that, that's not
the case for these kind of delays
astearns: If there were platform specific delays that were widely
used and people relied on, then I could see your point.
astearns: I don't think this is OS specific.
emilio: I agree it's not OS specific. It's more about - as a user...
I guess you could override with a user stylesheet, but it
loses the intent of making it short or long
masonf: I had the same concerns but user agents could have a setting
like "double all the delays" or clamp them to a range. As
long as the UA can override those specified by the developer,
as long as there's a mechanism.
astearns: I'd definitely support allowing UAs to override, but I
don't think we should build it around UA preferences.
PaulG: Multiplicative idea for UA setting would be great. WCAG 2.2.1
is 10x, so allowing user 10x time to do a task. If this were
part of that this would allow people to spend a lot less code
on a feature. Great progressive enhancement and accuracy
across user experiences
dholbert: Specifying exact time; the idea of letting UAs add
multipliers... I worry a little that with specifying exact
time, developers would coordinate animations with delays
which would look cool but would break with UA adjustments.
dholbert: it might not work in practice.
flackr: I wanted to make an argument against complete customization.
Couldn't UAs have a sensible tooltip delay that makes sense.
I've heard interesting ideas of how that could work such as
subsequent tooltips being instant - this could be something
the UA could do in general. The argument for this is that the
UA could provide a consistent experience across sites and
the OS.
flackr: this is why scrolling in general isn't customizable. Users
aren't surprised that sites don't change scroll
masonf: Is the point that we shouldn't allow customization, or
specific numbers?
flackr: Unless we have strong reason to believe that UA delays don't
work we should have UA determined.
masonf: Appreciate the feedback. I think I heard open questions;
specific delays might be better than named values. Different
delays based on modality, hover vs touch. Focus delay should
be zero, but I think there should be a non-zero focus delay
for folks tabbing in the document.
masonf: Should there be a pseudo class for first tooltip open, etc...
I'd love to have more feedback on the issue. Thanks for the
discussion
astearns: Is this going to form controls task force, or just tooltip
discussion?
masonf: I opened this issue about a year ago, but it's clear I need
to bring the tooltip issue to the task force as there are
wider questions. I don't know if this rises to that level.
CSS Selectors
=============
Should :not(foo) match the host of the shadow tree?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10179
TabAtkins: A question raised: what the `:not` pseudo class means wrt
the `:host` element. The point of it being featureless is
to avoid having to defensively think about what the outer
page is doing with the host element
TabAtkins: Should :not match everything but the host by default?
TabAtkins: Not should, by default, not match the host element by
default. Just like .foo wouldn't match, not(.foo) wouldn't.
TabAtkins: If you explicitly mention the host in the :not, you're
explicitly opting in, so there could be a small set of
rules for :not matching, compound selectors matching,
complex selectors are allowed to match only if the subject
compound is allowed to match
TabAtkins: This captures the notion of if the :not selector is caring
about the host element. If so it is allowed to match
otherwise it ignores like everything else.
TabAtkins: If this sounds reasonable I can write the edits
TabAtkins: I believe that brings all logical combinator pseudos into
a reasonable state wrt the host element
emilio: The only selector that would matter would be :not(:host)?
Other stuff would never match effectively?
TabAtkins: I believe so
emilio: Can we make this simpler and say it never matches? Given
:host is featureless
emilio: Is there a use case for :not(:host)?
TabAtkins: There are other things that could do that. Also :has().
You could potentially match a host element without :host,
and if you :not that, you could potentially match the
host...
TabAtkins: example:
<TabAtkins> if :has(.foo) doesn't match the host (but is allowed to),
the :not(:has(.foo)) would match the host
emilio: Do you really want :not(:has(.foo)) to really match?
TabAtkins: That's the next issue
emilio: I thought the next issue was :host:has() work
emilio: I think I see, it's very weird. In general I don't think you
can match the host with something which doesn't contain :host
TabAtkins: That's the next issue
astearns: Could we move forward with the complicated bits and drop
them if we don't need them?
TabAtkins: A selector X that's potentially able to match a set of
elements, X and :not(X) should match all those potential
elements, which may or may not include the host.
TabAtkins: That's the underpinning I want to resolve on
PROPOSED RESOLUTION: edit in what's described in Tabs last comment
RESOLVED: Edit in what's described in Tab's last comment
Should `:host:has()` match?
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/10693
<TabAtkins> :host:has(.foo)
TabAtkins: Someone added tests in WPT combining :host:has. Some test
well specified behaviour, but they added some tentative
about using :host:has next to each other in a compound
selector
TabAtkins: Tentatively wrote assuming this works and it matches the
host element assuming a .foo is in the tree
TabAtkins: That doesn't work because :has doesn't match featureless
elements in general
TabAtkins: The :has pseudo class should be able to match the host.
Again, :host is featureless because authors of the shadow
tree cannot predict the markup so it would have to be
written defensively
TabAtkins: The :has pseudo class only matches based on descendants,
ie stuff in the shadow tree thus already in control of the
author
TabAtkins: so predictable behavior and no defensive coding
TabAtkins: There's also some examples this satisfies in the thread
<TabAtkins> :host:has(.foo) and :has(.foo) both are allowed to match
TabAtkins: So :has should be added to the list of things to match the
host element
TabAtkins: Also unqualified :has(.foo) should be able to match the
host element
TabAtkins: This is potentially confusing because no selectors
currently match :host... nothing else can do this right
now so it might not be expected.
TabAtkins: The benefit of allowing is that matching behavior becomes
much more sensible if it is allowed to match unreservedly
TabAtkins: it makes speccing more complex if not
TabAtkins: the simpler model, I think, is a little better
<emilio> Feels wrong that `*:has(..)` and `:has(..)` behaves
differently
<TabAtkins> *:is(:host) and :is(:host) already match different
emilio: I get the use case of matching inside the shadow tree, I'm
not sure I agree with making it match when not qualified. It
feels wrong that * doesn't match but unqualified does.
emilio: I guess you're right that's already the case per spec
emilio: Something matching host that doesn't contain :host feels bad
emilio: I find it confusing. Especially as styles go outside your
component
emilio: Either force :host or do a new pseudo or something
emilio: I think I have a preference for enforcing :host especially as
it doesn't change the behaviour for unqualified selectors
TabAtkins: I suspect that unqualified :has is rare to non-existent as
it could potentially match all elements. I would be
surprised if it causes problems
TabAtkins: open to possibility that it would though
astearns: I didn't go into the use cases but are the use cases
presented for unqualified has that cannot be done with
qualified has? Or is it ergonomics?
TabAtkins: Purely ergonomics, purely a matter of ergonomics/spec
complexity to make it work one way or another
emilio: Implementation complexity implies there is a benefit, then
you can avoid looking at those selectors altogether
TabAtkins: But you would still know which selectors are potentially
able to match
TabAtkins: This expands the set of potential matches from things to
the :host to things with unqualified :has
emilio: :is also complicates, but if you have :host in the subject it
can only match the host. :has can match random stuff in the
tree
emilio: I think unqualified :has matching :host is not great as an
author
emilio: Other than my gut feeling I don't have strong arguments one
way or another
TabAtkins: Are you implying there's a benefit to saying these
selectors only apply to host or not? Being able to match
either host or shadow tree is more complex?
emilio: Yeah. We can put the selector in a separate place to style
the element, otherwise it's in the general place
TabAtkins: The spec side, it means adding another clause to the
conditions for what allows a compound selector to match a
host element
TabAtkins: Not a huge complexity but one more thing in the list
emilio: Spec or implementation complexity aside, I wonder what other
authors think? A bare :has with random stuff inside
accidentally matching the :host?
astearns: The person who wrote the tests is not thinking about this
accidentally perhaps
astearns: I'd like to see what the valid use case is. Speaking
personally, I think I'd like the use cases to justify this
TabAtkins: For the feature entirely? Or needing :host to be spelled
out?
astearns: Allowing a selector that doesn't explicitly use :host to
match the host
emilio: You claim the test author mentioned that? As far as I can
tell they don't test that
TabAtkins: All tests have :host:has. In the mindset of testing that
:host matches appropriately.
TabAtkins: I'm fine with resolving with emilio's amendment
<TabAtkins> :host:has() can match, :has() can't
PROPOSED RESOLUTION: :host:has() can match, :has() can't
oriol: I think this breaks the assumption from the previous issue
oriol: when we have compound selector allowed to match host, here has
wouldn't be allowed but the combination would
oriol: so it breaks the general rule?
TabAtkins: Changing that rule to special case this would be part of
that resolution
oriol: So what would the general rule be?
TabAtkins: I'll show the spec
RESOLVED: :host:has() can match, :has() can't
Received on Thursday, 15 August 2024 23:43:09 UTC