Meeting minutes
astearns: any changes people would like to make to the agenda?
fantasai: first public WD of css-values-5?
<fantasai> w3c/
astearns: let's start with that.
<astearns> github-bot, take up w3c/
Republishing Tasks Permathread
<github-bot> OK, I'll post this discussion to https://
<fantasai> https://
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
… 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: Im 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
RESOLUTION: 1 more calc-size edit in, then issue first working draft of css-values-5
github-bot, take up w3c/
[css-easing-2] Time for FPWD
<github-bot> OK, I'll post this discussion to https://
<TabAtkins> definitely +1 to easing-2 FPWD
ChrisL: this only adds 1 new feature: multipoint linear easing function. This is already widely implemented.
… proposal to add to Pre-CR exceptions. Which is awkward if its not FWD
… 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
RESOLUTION: Add ChrisL and TabAtkins for easing level 2 and publish FWD
github-bot, take up w3c/
Add hover/focus/long-press triggering delays to CSS
<github-bot> OK, I'll post this discussion to https://
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://
masonf: related to interest target proposal
… 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.
… use case are tooltips, hovering menus, other cases where the user hasn't yet clicked
… I don't think we want to debate the case just yet but we want to discuss the delays involved in this
… 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
… 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.
… 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
… there are two things, one is showing interest, the other is _losing_ interest, when you move away and want it to hide
… 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
… 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
… 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 usecases 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
… 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, thats 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 Ive 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
… a lot of people are concerned with specific times, especially wrt satisfying success criteria.
… so I'd say go towards focus/hover pseudos as a way to separate those out rather than token/values. Touch would be separate
… unless we add another pseudo but I don't think it would make a difference
… 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 normalise 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.
… usually we dont 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.
… So I agree we need this property but it should be more author configurable
… 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
… delay might want to be configurable based on presence of an active tooltip
… e.g. if you currently are looking at a tooltip, and are in a mystery menu
… you might want the delay to be shortened on subsequent things
… that is trivially expressable in CSS right now, but much harder in other languages
ydaniv: Agree with keith and roman. Anywhere we try to solve in keywords, it always failed.
<kizu> +1 to Keith, libs like Tippy have this as an option: https://
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: Anywhere we try to solve values with keywords where the UA can chose, it always fails. For example in scrolling. Smooth scrolling is left up to the UA. It looks different, different speed in different browsers, tons of backlash with that
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 dont have pixel values for scrollbars is because some OSes don't support changing that, that's not the case for these kind of delays
… if there we platform specific delays that were widely used and people relied on, then I could see your point.
… 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 221 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 progresssive 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.
… it might not work in practice.
flackr: I wanted to make an argument against complete customisation. 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.
… 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 customisation, 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.
… 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.
github-bot, take up w3c/
[selectors] Should :not(foo) match the host of the shadow tree?
<github-bot> OK, I'll post this discussion to https://
TabAtkins: a q 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
… should :not match everything but the host by default?
… not should, by default, not match the host element by default. Just like .foo wouldn't match, not(.foo) wouldn't.
… 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
… 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.
… if this sounds reasonable I can write the edits
… I believe that brings all logical combinator pseudos into a reasonable state wrt the host eleemnt
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
… 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...
… 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 dont 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 dont 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.
… that's the underpinning I want to resolve on
PROPOSED RESOLUTION: edit in what's described in Tabs last comment
RESOLUTION: edit in what's described in Tabs last comment
github-bot, take up w3c/
[selectors][css-scoping] Should `:host:has()` match?
<github-bot> OK, I'll post this discussion to https://
<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 eachother in a compound selector
… tentatively wrote assuming this works and it matches the host element assuming a .foo is in the tree
… that doesn't work because :has doesn't match featureless elements in general
… 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
… the :has pseudo class only matches based on descendents, ie stuff in the shadow tree thus already in control of the author
… so predictable behavior and no defensive coding
… 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
… also unqualified :has(.foo) should be able to match the host element
… This is potentially confusing because no selectors currently match :host... nothing else can do this right now so it might not be expected.
… The benefit of allowing is that matching behavior becomes much more sensible if it is allowed to match unreservedly
<emilio> Feels wrong that `*:has(..)` and `:has(..)` behaves differently
TabAtkins: it makes speccing more complex if not
… the simpler model, I think, is a little better
<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 * doesnt match but unqualified does.
… I guess you're right that's already the case per spec
… something matching host that doesnt contain :host feels bad
… I find it confusing. Especially as styles go outside your component
… either force :host or do a new pseudo or something
… 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
… 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
… 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
… other than my gut feeling I dont have strong arguments one way or another
TabAtkins: are you implying theres 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
… 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
… 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 ammendment
<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
… when we have compound selector allowed to match host, here has wouldnt be allowed but the combination would
… 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
RESOLUTION: :host:has() can match, :has() can't