15:53:22 <RRSAgent> RRSAgent has joined #css
15:53:27 <RRSAgent> logging to https://www.w3.org/2024/08/14-css-irc
15:53:28 <Zakim> RRSAgent, make logs Public
15:53:29 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:57:17 <SebastianZ> SebastianZ has joined #css
15:57:28 <masonf> masonf has joined #css
15:58:29 <kizu> kizu has joined #css
15:58:39 <ChrisL> present+
15:58:45 <masonf> present+
15:59:06 <SebastianZ> present+
15:59:06 <joshtumath> present+
15:59:11 <kizu> present+
16:00:22 <keithamus> present+
16:01:00 <dholbert> dholbert has joined #css
16:01:01 <ChrisL> regrets+ Lea
16:01:06 <flackr> present+
16:01:20 <dholbert> present+
16:01:35 <dbaron> Present+
16:02:00 <bramus> present+
16:02:16 <ydaniv> ydaniv has joined #css
16:02:30 <bkardell_> bkardell_ has joined #css
16:02:43 <rachelandrew> present+
16:02:48 <kbabbitt> kbabbitt has joined #css
16:02:51 <jfkthame> jfkthame has joined #css
16:03:10 <ydaniv> present+
16:03:18 <jfkthame> present+
16:03:22 <kbabbitt> present+
16:03:22 <keithamus> scribe+
16:03:46 <keithamus> astearns: any changes people would like to make to the agenda?
16:03:55 <keithamus> fantasai: first public WD of css-values-5?
16:04:03 <alisonmaher> alisonmaher has joined #css
16:04:09 <alisonmaher> present+
16:04:17 <fantasai> https://github.com/w3c/csswg-drafts/issues/6900
16:04:29 <ethanjv> ethanjv has joined #css
16:04:38 <bkardell_> present+
16:04:48 <emilio> present+
16:05:00 <argyle> present+
16:05:06 <keithamus> astearns: let's start with that.
16:05:13 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900
16:05:13 <github-bot> Topic: Republishing Tasks Permathread
16:05:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.
16:05:15 <emeyer> emeyer has joined #css
16:05:34 <fantasai> https://drafts.csswg.org/css-values-5/
16:05:46 <keithamus> 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
16:05:57 <keithamus> ... we should publish and tweak it, refine issues before we get to far along
16:06:02 <keithamus> astearns: what features?
16:06:24 <keithamus> fantasai: progress, cross fade, toggle attr, fade, random, random-item, sibling-count, sibling-index, interpolate-size...
16:06:31 <bts> bts has joined #css
16:06:33 <bts> present+
16:06:37 <keithamus> astearns: any concerns, those who want more time?
16:06:41 <schenney> schenney has joined #css
16:06:59 <keithamus> dbaron: Im supportive. One other edit for ??-size. I think it's fine but I'd like to make the edit first
16:07:09 <keithamus> fantasai: we can do that. Let's keep iterating from there.
16:07:11 <dbaron> s/??-size/calc-size that I was hoping to make today/
16:07:24 <keithamus> ChrisL: It takes a few days. It'll be friday at the earliest.
16:07:42 <miriam> present+
16:07:42 <keithamus> PROPOSED RESOLUTION: 1 more calc-size edit in, then issue first working draft of css-values-5
16:07:47 <keithamus> RESOLVED: 1 more calc-size edit in, then issue first working draft of css-values-5
16:08:12 <keithamus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10688
16:08:13 <github-bot> Topic: [css-easing-2] Time for FPWD
16:08:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10688.
16:08:19 <TabAtkins> definitely +1 to easing-2 FPWD
16:08:34 <keithamus> ChrisL: this only adds 1 new feature: multipoint linear easing function. This is already widely implemented.
16:08:47 <keithamus> ... proposal to add to Pre-CR exceptions. Which is awkward if its not FWD
16:08:56 <PaulG> PaulG has joined #css
16:08:58 <keithamus> ... I added WPT annotation so we can see how much is implemented. but it's in good shape
16:08:58 <astearns> ack fantasai
16:09:00 <PaulG> present+
16:09:06 <keithamus> fantasai: should we add another editor?
16:09:27 <keithamus> TabAtkins: I've already been doing some edits so happy to add to my pile
16:09:36 <keithamus> ChrisL: I would but I've got many things, not as much as Tab
16:09:41 <keithamus> fantasai: maybe we add both?
16:09:46 <keithamus> ChrisL: fine
16:10:10 <keithamus> PROPOSED RESOLUTION: Add ChrisL and TabAtkins for easing level 2 and publish FWD
16:10:18 <keithamus> RESOLVED: Add ChrisL and TabAtkins for easing level 2 and publish FWD
16:10:59 <keithamus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9236
16:10:59 <github-bot> Topic: Add hover/focus/long-press triggering delays to CSS
16:10:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9236.
16:11:34 <keithamus> 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.
16:11:39 <masonf> - Explainer: https://open-ui.org/components/interest-invokers.explainer
16:11:40 <keithamus> ... related to interest target proposal
16:12:32 <keithamus> ... 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.
16:12:44 <keithamus> ... use case are tooltips, hovering menus, other cases where the user hasn't yet clicked
16:12:59 <keithamus> ... I don't think we want to debate the case just yet but we want to discuss the delays involved in this
16:13:38 <keithamus> ... 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
16:13:48 <flackr> q+
16:14:16 <keithamus> ... 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.
16:14:26 <astearns> q+
16:14:44 <keithamus> ... 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
16:15:04 <keithamus> ... there are two things, one is showing interest, the other is _losing_ interest, when you move away and want it to hide
16:15:31 <emilio> q+
16:15:39 <keithamus> ... 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
16:15:56 <oriol>   present+
16:16:00 <keithamus> ... 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.
16:16:07 <astearns> ack flackr
16:16:35 <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.
16:16:52 <keithamus> 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
16:17:22 <keithamus> ... 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
16:17:52 <PaulG> q+
16:17:52 <keithamus> 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
16:18:07 <keithamus> ... there is already `title` attribute which users complain is too long
16:18:17 <keithamus> flackr: we should change that if the common feedback is the delay is too long
16:18:21 <keithamus> masonf: I don't disagree
16:18:41 <kizu> q+
16:18:42 <keithamus> astearns: different timing for different affordances could be something in HTML. Different built-in timings for that.
16:18:43 <kbabbitt> q+
16:18:46 <keithamus> q+
16:19:04 <keithamus> astearns: Would we need a `never` or some other value that stays shown until you hover over the next one?
16:19:42 <keithamus> 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
16:19:44 <astearns> ack astearns
16:20:11 <TabAtkins> I can definitely say that debouncing correctly is much harder than one would think.
16:20:17 <TabAtkins> (I'm doing that in JS for Bikeshed.)
16:20:21 <astearns> ack emilio
16:20:26 <keithamus> 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
16:21:33 <keithamus> 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
16:21:34 <keithamus> infra, but maybe that's wrong?
16:22:01 <keithamus> 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
16:22:54 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html fantasai
16:23:10 <keithamus> 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
16:23:43 <astearns> ack PaulG
16:23:44 <keithamus> 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
16:23:51 <ydaniv> q+
16:24:21 <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?)
16:24:36 <emilio> But yeah the general thing seems worth exploring
16:24:51 <keithamus> 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
16:24:52 <keithamus> as a specific time
16:25:05 <keithamus> ... a lot of people are concerned with specific times, especially wrt satisfying success criteria.
16:25:27 <keithamus> ... so I'd say go towards focus/hover pseudos as a way to separate those out rather than token/values. Touch would be separate
16:25:41 <keithamus> ... unless we add another pseudo but I don't think it would make a difference
16:26:01 <keithamus> ... everything else seems to be answered by the writeup but I'd like to see other use cases. What seems to far afield?
16:26:03 <astearns> ack kizu
16:27:36 <keithamus> 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
16:27:36 <keithamus> 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.
16:28:48 <keithamus> ... 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
16:28:48 <keithamus> none elements lose events, so you cannot have transition on display.
16:29:01 <keithamus> ... So I agree we need this property but it should be more author configurable
16:29:08 <keithamus> ... e.g. games might want immediate responses.
16:29:13 <astearns> ack kbabbitt
16:30:06 <keithamus> 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.
16:30:10 <fantasai> scribe+
16:30:17 <astearns> ack keithamus
16:30:26 <fantasai> keithamus: One use case I want to represent, where CSS feels appropriate
16:30:35 <fantasai> ... delay might want to be configurable based on presence of an active tooltip
16:30:45 <fantasai> ... e.g. if you currently are looking at a tooltip, and are in a mystery menu
16:31:02 <fantasai> ... you might want the delay to be shortened on subsequent things
16:31:15 <fantasai> ... that is trivially expressable in CSS right now, but much harder in other languages
16:31:21 <astearns> ack ydaniv
16:31:43 <fantasai> ydaniv: Agree with keith and roman. Anywhere we try to solve in keywords, it always failed.
16:31:49 <kizu> +1 to Keith, libs like Tippy have this as an option: https://atomiks.github.io/tippyjs/v6/addons/#singleton
16:32:04 <fantasai> ... 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
16:32:06 <keithamus> 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
16:32:53 <keithamus> 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.
16:32:55 <emilio> q+
16:32:56 <masonf> q?
16:33:03 <astearns> ack emilio
16:33:17 <andreubotella> andreubotella has joined #css
16:33:30 <PaulG> q+
16:33:40 <keithamus> 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.
16:34:06 <keithamus> 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
16:34:27 <keithamus> ... if there we platform specific delays that were widely used and people relied on, then I could see your point.
16:34:35 <keithamus> ... I don't think this is OS specific.
16:35:03 <keithamus> 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
16:35:39 <keithamus> 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.
16:35:53 <dholbert> q+
16:35:57 <keithamus> astearns: I'd definitely support allowing UAs to override, but I don't think we should build it around UA preferences.
16:36:00 <astearns> ack PaulG
16:36:28 <flackr> q+
16:36:45 <astearns> ack dholbert
16:36:45 <keithamus> 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
16:37:31 <keithamus> 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.
16:37:38 <keithamus> ... it might not work in practice.
16:37:43 <astearns> ack flackr
16:37:48 <masonf> q+
16:38:48 <keithamus> 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
16:38:48 <keithamus> experience across sites and the OS.
16:39:05 <astearns> ack masonf
16:39:09 <keithamus> ... this is why scrolling in general isn't customizable. Users aren't surprised that sites don't change scroll
16:39:20 <keithamus> masonf: Is the point that we shouldn't allow customisation, or specific numbers?
16:39:30 <kizu> q+
16:39:45 <keithamus> flackr: unless we have strong reason to believe that UA delays don't work we should have UA determined.
16:39:54 <kizu> q- will comment in the issue
16:40:16 <kizu> q- to comment in the issue
16:40:37 <keithamus> 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.
16:40:57 <keithamus> ... 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
16:41:07 <keithamus> astearns: Is this going to form controls task force, or just tooltip discussion?
16:41:32 <keithamus> 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.
16:41:50 <keithamus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10179
16:41:50 <github-bot> Topic: [selectors] Should :not(foo) match the host of the shadow tree?
16:41:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10179.
16:42:22 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html fantasai
16:42:29 <keithamus> 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
16:42:53 <keithamus> ... should :not match everything but the host by default?
16:42:55 <SebastianZ> SebastianZ has joined #css
16:43:17 <keithamus> ... not should, by default, not match the host element by default. Just like .foo wouldn't match, not(.foo) wouldn't.
16:43:53 <keithamus> ... 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
16:44:12 <keithamus> ... 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.
16:44:18 <keithamus> ... if this sounds reasonable I can write the edits
16:44:26 <emilio> q+
16:44:33 <astearns> ack emilio
16:44:35 <keithamus> ... I believe that brings all logical combinator pseudos into a reasonable state wrt the host eleemnt
16:44:51 <keithamus> emilio: the only selector that would matter would be :not(:host)? Other stuff would never match effectively?
16:44:55 <keithamus> TabAtkins: I believe so
16:45:14 <keithamus> emilio: can we make this simpler and say it never matches? Given :host is featureless
16:45:18 <keithamus> ... is there a use case for :not(:host)?
16:45:44 <keithamus> 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...
16:45:48 <keithamus> ... example:
16:46:02 <TabAtkins> if :has(.foo) doesn't match the host (but is allowed to), the :not(:has(.foo)) would match the host
16:46:32 <keithamus> emilio: do you really want :not(:has(.foo)) to really match?
16:46:36 <keithamus> TabAtkins: that's the next issue
16:46:44 <keithamus> emilio: I thought the next issue was :host(:has work
16:47:10 <keithamus> 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
16:47:15 <keithamus> TabAtkins: that's the next issue
16:47:31 <keithamus> astearns: Could we move forward with the complicated bits and drop them if we dont need them?
16:48:29 <keithamus> TabAtkins: a selector X that's potentially able to match a set of elements, X and :not(X) should match all elements, which may or may not include the host.
16:48:37 <keithamus> ... that's the underpinning I want to resolve on
16:48:46 <TabAtkins> s/match all elements/match all those potential elements/
16:49:22 <keithamus> PROPOSED RESOLUTION: edit in what's described in Tabs last comment
16:49:25 <keithamus> RESOLVED: edit in what's described in Tabs last comment
16:49:39 <keithamus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10693
16:49:39 <github-bot> Topic: [selectors][css-scoping] Should `:host:has()` match?
16:49:39 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10693.
16:50:18 <TabAtkins> :host:has(.foo)
16:50:22 <keithamus> 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
16:50:37 <keithamus> ... tentatively wrote assuming this works and it matches the host element assuming a .foo is in the tree
16:50:48 <keithamus> ... that doesn't work because :has doesn't match featureless elements in general
16:51:22 <keithamus> ... 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
16:51:54 <emilio> q+
16:51:55 <keithamus> ... the :has pseudo class only matches based on descendents, ie stuff in the shadow tree thus already in control of the author
16:52:05 <keithamus> ... so predictable behavior and no defensive coding
16:52:18 <keithamus> ... there's also some examples this satisfies in the thread
16:52:33 <TabAtkins> :host:has(.foo) and :has(.foo) both are allowed to match
16:52:40 <keithamus> ... so :has should be added to the list of things to match the host element
16:52:56 <keithamus> ... also unqualified :has(.foo) should be able to match the host element
16:53:18 <keithamus> ... This is potentially confusing because no selectors currently match :host... nothing else can do this right now so it might not be expected.
16:53:35 <keithamus> ... The benefit of allowing is that matching behavior becomes much more sensible if it is allowed to match unreservedly
16:53:43 <emilio> Feels wrong that `*:has(..)` and `:has(..)` behaves differently
16:53:44 <keithamus> ... it makes speccing more complex if not
16:53:53 <keithamus> ... the simpler model, I think, is a little better
16:53:55 <astearns> ack emilio
16:54:13 <TabAtkins> *:is(:host) and :is(:host) already match different
16:54:29 <keithamus> 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.
16:54:37 <keithamus> ... I guess you're right that's already the case per spec
16:54:47 <keithamus> ... something matching host that doesnt contain :host feels bad
16:54:57 <keithamus> ... I find it confusing. Especially as styles go outside your component
16:55:09 <keithamus> ... either force :host or do a new pseudo or something
16:55:10 <astearns> q+
16:55:33 <keithamus> ... I think I have a preference for enforcing :host especially as it doesn't change the behaviour for unqualified selectors
16:56:02 <keithamus> 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
16:56:10 <keithamus> ... open to possibility that it would though
16:56:35 <astearns> ack astearns
16:56:36 <keithamus> 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
16:56:51 <keithamus> TabAtkins: purely ergonomics, purely a matter of ergonomics/spec complexity to make it work one way or another
16:57:07 <keithamus> emilio: implementation complexity implies there is a benefit, then you can avoid looking at those selectors altogether
16:57:22 <keithamus> TabAtkins: but you would still know which selectors are potentially able to match
16:57:43 <keithamus> ... this expands the set of potential matches from things to the :host to things with unqualified :has
16:58:04 <keithamus> 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
16:58:18 <keithamus> emilio: I think unqualified :has matching :host is not great as an author
16:58:30 <keithamus> ... other than my gut feeling I dont have strong arguments one way or another
16:58:58 <keithamus> 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?
16:59:16 <keithamus> emilio: yeah. We can put the selector in a separate place to style the element, otherwise it's in the general place
17:00:08 <keithamus> TabAtkins: the spec side, it means adding another clause to the conditions for what allows a compound selector to match a host element
17:00:14 <keithamus> ... not a huge complexity but one more thing in the list
17:00:36 <keithamus> emilio: spec or implementation complexity aside, I wonder what other authors think? A bare :has with random stuff inside accidentally matching the :host?
17:00:52 <keithamus> astearns: the person who wrote the tests is not thinking about this accidentally perhaps
17:01:19 <keithamus> ... I'd like to see what the valid use case is. Speaking personally, I think I'd like the use cases to justify this
17:01:27 <keithamus> TabAtkins: for the feature entirely? Or needing :host to be spelled out?
17:01:40 <keithamus> astearns: allowing a selector that doesn't explicitly use :host to match the host
17:01:55 <keithamus> emilio: you claim the test author mentioned that? As far as I can tell they don't test that
17:02:14 <keithamus> TabAtkins: all tests have :host:has. In the mindset of testing that :host matches appropriately.
17:02:25 <keithamus> TabAtkins: I'm fine with resolving with emilio's ammendment
17:02:42 <TabAtkins> :host:has() can match, :has() can't
17:03:05 <keithamus> PROPOSED RESOLUTION: :host:has() can match, :has() can't
17:03:05 <oriol> q+
17:03:18 <keithamus> oriol: I think this breaks the assumption from the previous issue
17:03:33 <keithamus> ... when we have compound selector allowed to match host, here has wouldnt be allowed but the combination would
17:03:37 <keithamus> ... so it breaks the general rule?
17:03:46 <keithamus> TabAtkins: changing that rule to special case this would be part of that resolution
17:03:54 <keithamus> oriol: so what would the general rule be?
17:03:57 <keithamus> TabAtkins: I'll show the spec
17:04:02 <keithamus> RESOLVED: :host:has() can match, :has() can't
17:04:23 <astearns> topic: end
17:38:46 <astearns> zakim, end meeting
17:38:46 <Zakim> As of this point the attendees have been ChrisL, masonf, SebastianZ, joshtumath, kizu, keithamus, flackr, dholbert, dbaron, bramus, rachelandrew, ydaniv, jfkthame, kbabbitt,
17:38:49 <Zakim> ... alisonmaher, bkardell_, emilio, argyle, TabAtkins, bts, miriam, PaulG, oriol
17:38:49 <Zakim> RRSAgent, please draft minutes v2
17:38:50 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/14-css-minutes.html Zakim
17:38:56 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:38:56 <Zakim> Zakim has left #css