- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 13:42:43 +0000
- To: public-css-archive@w3.org
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> <fantasai> schenney: There's a "current" search term, and inactive ones<br> <fantasai> schenney: "current" one being the one that would be selected if you exit the search UI<br> <fantasai> schenney: we resolved to use :current pseudo-class to distinguish that case<br> <fantasai> schenney: issue that the existing syntax for :current has a functional form, and what should we do about that<br> <fantasai> schenney: should we do it or ignore it or what<br> <fantasai> schenney: I think we just don't allow it<br> <emeyer> fantasai: I think that makes sense<br> <fantasai> schenney: when :current is used with ::search-text, the functional form is invalid<br> <emilio> q+<br> <astearns> ack emilio<br> <fantasai> emilio: it feels a bit weird to re-use WebVTT pseudos for this<br> <fantasai> emilio: in particular :current also matches ancestors, which is not what you want<br> <fantasai> emilio: you only really want it to match the pseudo-element<br> <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> <fantasai> emilio: Maybe clarify spec to say what it means for these pseudos<br> <fantasai> emilio: given you're re-using the state, good as anything else<br> <fantasai> emilio: I guess the name is fine as long as we fix up the definition<br> <fantasai> schenney: short of redefining it, is to come up with another word that still conveys the meaning<br> <emeyer> fantasai: I think if it's reasonable from an implementation point of view, it's author-reasonable, and we should keep it<br> <emeyer> fantasai: pseudo-classes that attach to pseudo-elements are in their own little world, but this seems a usable solution<br> <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> <emeyer> fantasai: I don't think that was ever implemented, but it was there<br> <emeyer> fantasai: Find-in-page doesn't seem to be inconsistent with those<br> <emilio> q+<br> <astearns> ack emilio<br> <fantasai> astearns: so proposal to make :current() invalid with ::search-text<br> <fantasai> emilio: One concern<br> <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> <fantasai> emilio: idk if we have precedent for only parsing a pseudo-element in certaint spots<br> <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> <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> <fantasai> emilio: [missed]<br> <fantasai> bramus: could you rename to :current-match?<br> <fantasai> fantasai: it's a bit redundant<br> <emilio> s/[missed]/`@supports (:current) {` would be true if you implements either feature, which is a bit unfortunate<br> <astearns> s/[missed]/my concern is not being able to distinguish the :current usages in @supports/<br> <fantasai> schenney: but solves some issues<br> <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> <emeyer> fantasai: You can do something like, I guess it depends on how much we restrict selectors<br> <fantasai> selector(::search-text:current)<br> <khush> q+<br> <emeyer> fantasai: That could return false if you don't support it and true if you do<br> <fantasai> astearns: if there's a way to disambiguate the @supports calls, that's sufficient<br> <astearns> ack khush<br> <fantasai> khush: Is there a reason to re-use the current pseudo-class rather than creating something new<br> <fantasai> schenney: That was Alan's point about introducing a new name every time we need something that means roughly the same thing<br> <fantasai> khush: I like :selected<br> <emeyer> fantasai: I think the problem with :selected is it sounds like ::selection<br> <emeyer> fantasai: Until we come up with something much better, I think :selected works reasonably well<br> <emeyer> …I think we need to make sure invalid selector combinatoins return false<br> <emeyer> …I’m not sure how clear we are on that point<br> <emeyer> …I’m open to other solutions to this problem, but I sympathize with Alan's argument<br> <florian> +1<br> <emeyer> …Doing this seems like a win from an authoring perspective rather than continuing to come up with synonyms in different contexts<br> <fantasai> schenney: so :current() will never match ::search-text<br> <fantasai> astearns: Proposed resolution ^<br> <fantasai> astearns: any objections?<br> <schenney> current(x,y) never matches in search-text<br> <fantasai> RESOLVED: :current() will never match ::search-text<br> <fantasai> astearns: do we need to update the description?<br> <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