- 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