Re: [csswg-drafts] [selectors-4][css-pseudo-4] meaning of ::search-text:current(…), :past, :future (#10298)

The CSS Working Group just discussed `[selectors-4][css-pseudo-4] meaning of ::search-text:current(…), :past, :future`, and agreed to the following:

* `RESOLVED: :current() will never match ::search-text`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> schenney: There's a "current" search term, and inactive ones<br>
&lt;fantasai> schenney: "current" one being the one that would be selected if you exit the search UI<br>
&lt;fantasai> schenney: we resolved to use :current pseudo-class to distinguish that case<br>
&lt;fantasai> schenney: issue that the existing syntax for :current has a functional form, and what should we do about that<br>
&lt;fantasai> schenney: should we do it or ignore it or what<br>
&lt;fantasai> schenney: I think we just don't allow it<br>
&lt;emeyer> fantasai: I think that makes sense<br>
&lt;fantasai> schenney: when :current is used with ::search-text, the functional form is invalid<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: it feels a bit weird to re-use WebVTT pseudos for this<br>
&lt;fantasai> emilio: in particular :current also matches ancestors, which is not what you want<br>
&lt;fantasai> emilio: you only really want it to match the pseudo-element<br>
&lt;fantasai> schenney: When we were figuring out the speudo-class names, the decision was to re-use :current. But not clear that it's the same :current as used in compound selectors<br>
&lt;fantasai> emilio: Maybe clarify spec to say what it means for these pseudos<br>
&lt;fantasai> emilio: given you're re-using the state, good as anything else<br>
&lt;fantasai> emilio: I guess the name is fine as long as we fix up the definition<br>
&lt;fantasai> schenney: short of redefining it, is to come up with another word that still conveys the meaning<br>
&lt;emeyer> fantasai: I think if it's reasonable from an implementation point of view, it's author-reasonable, and we should keep it<br>
&lt;emeyer> fantasai: pseudo-classes that attach to pseudo-elements are in their own little world, but this seems a usable solution<br>
&lt;emeyer> fantasai: The current ones were defined in a generic way, so you could for example have :current match the element being read out<br>
&lt;emeyer> fantasai: I don't think that was ever implemented, but it was there<br>
&lt;emeyer> fantasai: Find-in-page doesn't seem to be inconsistent with those<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> astearns: so proposal to make :current() invalid with ::search-text<br>
&lt;fantasai> emilio: One concern<br>
&lt;fantasai> emilio: Should an implementation that doesn't implement :current but wants to implement find-in-page stuff, should it treat :current as invalid outside it?<br>
&lt;fantasai> emilio: idk if we have precedent for only parsing a pseudo-element in certaint spots<br>
&lt;emeyer> fantasai: I think the resolution shouldn't be that it's parse-time invalid but that ::search-text can never match the same thing as current<br>
&lt;fantasai> fantasai: because :current() matchs an element that is matched by its argument, and a pseudo-element can never match a non-pseudo selector<br>
&lt;fantasai> emilio: [missed]<br>
&lt;fantasai> bramus: could you rename to :current-match?<br>
&lt;fantasai> fantasai: it's a bit redundant<br>
&lt;emilio> s/[missed]/`@supports (:current) {` would be true if you implements either feature, which is a bit unfortunate<br>
&lt;astearns> s/[missed]/my concern is not being able to distinguish the :current usages in @supports/<br>
&lt;fantasai> schenney: but solves some issues<br>
&lt;fantasai> astearns: It would not be good to come up with new names for all kinds of selectors just to fit it into @supports<br>
&lt;emeyer> fantasai: You can do something like, I guess it depends on how much we restrict selectors<br>
&lt;fantasai> selector(::search-text:current)<br>
&lt;khush> q+<br>
&lt;emeyer> fantasai: That could return false if you don't support it and true if you do<br>
&lt;fantasai> astearns: if there's a way to disambiguate the @supports calls, that's sufficient<br>
&lt;astearns> ack khush<br>
&lt;fantasai> khush: Is there a reason to re-use the current pseudo-class rather than creating something new<br>
&lt;fantasai> schenney: That was Alan's point about introducing a new name every time we need something that means roughly the same thing<br>
&lt;fantasai> khush: I like :selected<br>
&lt;emeyer> fantasai: I think the problem with :selected is it sounds like ::selection<br>
&lt;emeyer> fantasai: Until we come up with something much better, I think :selected works reasonably well<br>
&lt;emeyer> …I think we need to make sure invalid selector combinatoins return false<br>
&lt;emeyer> …I’m not sure how clear we are on that point<br>
&lt;emeyer> …I’m open to other solutions to this problem, but I sympathize with Alan's argument<br>
&lt;florian> +1<br>
&lt;emeyer> …Doing this seems like a win from an authoring perspective rather than continuing to come up with synonyms in different contexts<br>
&lt;fantasai> schenney: so :current() will never match ::search-text<br>
&lt;fantasai> astearns: Proposed resolution ^<br>
&lt;fantasai> astearns: any objections?<br>
&lt;schenney> current(x,y) never matches in search-text<br>
&lt;fantasai> RESOLVED: :current() will never match ::search-text<br>
&lt;fantasai> astearns: do we need to update the description?<br>
&lt;fantasai> schenney: I think we just need to update the search-text spec<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10298#issuecomment-2163045142 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 June 2024 13:42:44 UTC