- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 02 Jul 2025 16:28:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Pseudo classes for the `interestfor` API``.
<details><summary>The full IRC log of that discussion</summary>
<emilio> masonf: we talked a bit about this API in the past for `interest-{show,hide}-delay`<br>
<emilio> ... fyi the attribute is probably going to get renamed to `interestfor`<br>
<emilio> ... so these are things that match while the user shows interest (e.g. hover or keyboard focus)<br>
<emilio> ... there are two pseudo-classes in the last comment, the `invoker` and the `target`<br>
<emilio> ... then there are two levels<br>
<emilio> ... partial (with keyboard focus) and full interest<br>
<emilio> ... also another proposal to suggest possible interest<br>
<astearns> q+<br>
<astearns> ack fantasai<br>
<emilio> ... so current proposal is two functional pseudo-classes `:interest-{target,invoker}()`<br>
<lea> partial interest seems like a confusing concept. Reading the explainer, perhaps something around "delayed" or "future" interest? Is there partial interest that is not around that?<br>
<emilio> ... with values of `possible`, `partial`, and `total`<br>
<emilio> ... you can use them without the parens<br>
<emilio> ... which means `(total)`<br>
<emilio> ... qs are general shape<br>
<emilio> ... questions about the "possible"<br>
<emilio> q+<br>
<emilio> ... e.g. should the target exist and be valid<br>
<emilio> ... also whether the target should support possible<br>
<emilio> ... that'd require to know whether something points to it<br>
<astearns> ack astearns<br>
<emilio> astearns: so possible should be only for valid interestfor values...?<br>
<bkardell> q+<br>
<emilio> ... anything less than that is not a possible match<br>
<astearns> ack emilio<br>
<emilio> masonf: I think that makes sense<br>
<masonf> q+<br>
<bkardell> q-<br>
<bkardell> q+<br>
<emilio> emilio: I think we shouldn't do possible<br>
<emilio> ... since it seems it'd require / want to check whether something is focusable / hoverable as well, and that's trivially cyclic?<br>
<emilio> ... unless there's a very strong use case for it I'd at the very least defer it<br>
<emilio> masonf: The cyclic part is a great observation I hadn't noticed<br>
<emilio> ... the possible value was discussed in the middle of the issue<br>
<emilio> ... was brought up as sugar for `[interestfor]`<br>
<astearns> q+<br>
<astearns> ack masonf<br>
<emilio> ... it was not brought up whether it actually needs to be focusable or so<br>
<emilio> ... I'm agnostic to the possible value so if it causes issues I'm ok dropping it<br>
<astearns> ack bkardell<br>
<emilio> bkardell: the possible thing does seem a little dizzy to me too<br>
<emilio> ... we don't have a hoverable / focusable pseudo-class<br>
<emilio> ... I kinda wish we did?<br>
<astearns> s/dizzy/dicey<br>
<emilio> ... but I'd rather have those than this<br>
<masonf> :-)<br>
<lea> +1 to bkardell, a :focusable class is sorely needed, and very hard to emulate<br>
<emilio> astearns: Is `partial` actually needed?<br>
<astearns> ack astearns<br>
<emilio> ... could we start with the non-functional versions, then decide partial / etc?<br>
<emilio> masonf: that one was the genesis of the pseudo-class<br>
<lea> q?<br>
<bkardell> lea: it would need more than that I guess, since you can have things that have nuance too - what does it mean to be focusable isn't necessarily just binary<br>
<emilio> ... in the partial interest state the popover wants to have a hint text<br>
<bkardell> q+<br>
<emilio> ... so we wanted to provide that hint in the UA stylesheet<br>
<emilio> ... and we'd rather not do magic<br>
<emilio> astearns: haven't thought about it too deeply, but that interest-partial thing is the interesttarget, then there's the second level of "i've done a thing to show something else"<br>
<emilio> masonf: if the popover contains a button the user would have to do something else to get to the button<br>
<astearns> ack bkardell<br>
<emilio> bkardell: not sure if we're talking about this but there's some disagreement over whether this is currently possible, because FF and apple don't support this if we can't find a way to actually do it on mobile<br>
<emilio> ... there was a thing added the other day to add a pseudo-element<br>
<emilio> ... does this relate to that?<br>
<emilio> q+<br>
<emilio> bkardell: if we have that pseudo-element, does the pseudo-classes apply?<br>
<emilio> masonf: there are issues for this, those are rather unrelated<br>
<emilio> ... all of these pseudo-classes apply in the same way<br>
<bkardell> but wouldn't the pseudo be the thing that got interest?<br>
<lea> q+<br>
<lea> qq+<br>
<astearns> ack fantasai<br>
<emilio> ... whether the pseudo exists<br>
<bkardell> the apple webkit team at least :)<br>
<emilio> fantasai: we want to echo the concerns about making this work on mobile on the feature over-all, on the naming question I think interest-target is a bit ambiguous, because the target of your interest is the invoker<br>
<emilio> masonf: the attribute is not interesttarget anymore, it's interestfor<br>
<emilio> fantasai: you're proposing `:interest-target`<br>
<lea> +1 fantasai<br>
<bkardell> woof<br>
<emilio> ... which represent that things that triggered the interest which is the invoker<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to react to bkardell<br>
<astearns> ack lea<br>
<fantasai> maybe :interest-details?<br>
<emilio> lea: wanted to ask about the pseudo-element<br>
<emilio> ... IIUC that'd be a pseudo-element that would go from the target to the popover<br>
<emilio> ... that'd be a pseudo-element on the invoker<br>
<emilio> ... to provide a button on the side for touch-screen users<br>
<bkardell> it is like a (?) button<br>
<emilio> masonf: it'd be a button that shows e.g. the context menu<br>
<emilio> lea: Oh I thought that it went from the invoker to the popup<br>
<emilio> ... which would be a combinator<br>
<emilio> ... which would also be useful<br>
<fantasai> s/which represent that things that triggered the interest which is the invoker/but the target of your interest is :interest-invoker, and not :interest-target; so that's confusing/<br>
<emilio> masonf: had not heard that suggestion, can open one<br>
<bkardell> there is a long /for/ thing going back like 100 years<br>
<fantasai> scribe+ fantasai<br>
<bkardell> I don't see why this would be diff<br>
<astearns> ack emilio<br>
<fantasai> emilio: trying to keep about pseudo-classes in particular. Are there other use cases for this other than telling the user how to fully activate the popover?<br>
<fantasai> emilio: if not, I'm doubtful of the pseudo-element approach in the style sheet<br>
<fantasai> emilio: if we use an existing pseudo-element, authors may want to use fo rother thing<br>
<fantasai> emilio: Also don't want to show it all the time, once the user has opened doesn't need instructions anymore<br>
<lea> q?<br>
<fantasai> emilio: Just doesn't seem useful to have the partial option<br>
<fantasai> masonf: primary use case is that<br>
<fantasai> masonf: 2 things: instructions for the user -- which could be handled by UA -- but the problem with that is that the site might know whether it's needed or covered elsewhere or already known by user etc.<br>
<fantasai> masonf: also styleability, e.g. fading in/out<br>
<fantasai> emilio: Should the unparenthesized pseudo-class match both partial and total. Is there a reason for the default to be full interest?<br>
<fantasai> masonf: Subtle question of whether full interest includes partial.<br>
<fantasai> masonf: prototype is that full is a superset of partial<br>
<fantasai> masonf: reason for that is it feels more useful<br>
<fantasai> masonf: partial interest is a corner case<br>
<bkardell> it does seem like pseudo classes generally are more like the way Emilio mentions<br>
<fantasai> masonf: does this thing have interest at all or not<br>
<fantasai> masonf: so I thought shorthand should be total<br>
<fantasai> emilio: That's not how I would have expected total to work?<br>
<fantasai> <fantasai> +1<br>
<fantasai> emilio: I would expect total to only match when not partial<br>
<fantasai> emilio: I would expect partial and total to be exclusive<br>
<fantasai> emilio: and unparenthesized one to match both<br>
<fantasai> <fantasai> +1<br>
<fantasai> masonf: Third state, empty args with parens<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<fantasai> masonf: main usage will be unparenthesized, and that should match either partial or full<br>
<fantasai> masonf: I think as long as way to do this, it's ok<br>
<astearns> ack fantasai<br>
<fantasai> masonf: Does what emilio suggested make sense?<br>
<fantasai> astearns: It does constrain us if we want to add other parameters<br>
<fantasai> astearns: would need to also match with no-parens to be consistent<br>
<bkardell> Maybe that would/should be a separate issue<br>
<emilio> masonf: I don't think that'd be very useful if we add partial<br>
<bkardell> just like I said with focusable and hoverable<br>
<fantasai> astearns: Go back to issue, and consider additional parameters<br>
<emilio> astearns: let's take it back to the issue and move partial to a separate one<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12154#issuecomment-3028501403 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 July 2025 16:28:39 UTC