[selectors-4][css-pseudo-4] meaning of ::search-text:current(…), :past, :future

[delan]

We resolved that ::search-text (#3812) should have a :current (#10212) state for the active search result, but :current also has a functional form, where :current(x, y) matches any current element (or innermost ancestor) that also matches x, y, as well as the related pseudo-classes :past and :future.

0. Is the list of compound selectors in :current(…) a <forgiving-selector-list>? On the one hand, selector lists are normally invalid when they contain an invalid selector, but on the other hand, “like ‘:is()’” suggests it should be forgiving. If so, we should also update this note.

1. What does ::search-text:current(x, y) mean? Does it mean the innermost x or y that contains the active search result (which we probably want to forbid, since it would allow highlights to affect layout), or the ::search-text of that innermost x or y (which may have tricky :has()-like perf implications), or something else? We propose that ::search-text:current(…) be invalid, for now.

2. What do ::search-text:past and ::search-text:future mean? We propose that these also be invalid, for now, since no known UA distinguishes between search results on either “side” of :current.

[css-meeting-bot]

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

The full IRC log of that discussion

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

[delan]

We resolved that :current(…) will never match inside ::search-text, but there are still some unanswered questions:

0. Outside of highlight pseudos, is the list of compound selectors in :current(…) a <forgiving-selector-list>? On the one hand, selector lists are normally invalid when they contain an invalid selector, but on the other hand, “like ‘:is()’” suggests it should be forgiving. If so, we should also update this note.

1. Is ::search-text:current(…) also an invalid selector, or just a selector that never matches? In other words, does a rule like a, ::search-text:current(b) {} match a? Per selectors #pseudo-element-states, pseudo combinations that are not explicitly allowed are invalid selectors, so we propose that this be an invalid selector.

2. What about :past and :future? We propose that these be invalid selectors under ::search-text.