[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.

[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: Make :past and :future invalid for now, to reserve them for future use
• RESOLVED: Make the functional form of :current also invalid for highlight pseudos

The full IRC log of that discussion

<TabAtkins> ...i feel like I might have missed the May 1 2024 meeting where we decided to reuse the timed text pseudos
<kbabbitt> schenney: in a previous resolution we decided to use current as the thing to mean prioritized search text element
<kbabbitt> ... don't want to revisit that naming
<kbabbitt> ... also a function name also notion of past and future
<TabAtkins> q+
<kbabbitt> ... should we just say everything other than function al form of current and past and future are all invalid
<florian> q+
<kbabbitt> ... should have been not allowed, should it be invalid selector or selector that doesn't match
<astearns> ack TabAtkins
<kbabbitt> TabAtkins: would need to check but given I didn't comment in previous minutes...
<kbabbitt> ...do want to revisit naming actually
<kbabbitt> .. weird to reuse webvtt pseudoes
<kbabbitt> ... given that they don't match in the same way
<kbabbitt> ... appears to have purely been we want a pseudo that represents current thing, current exits, let's use that
<kbabbitt> ...without consideration that it doesn't follow previous concepts
<kbabbitt> ... think we should revisit, or rename the time pseudo classes
<kbabbitt> ... since this has come up before
<kbabbitt> ... we tried to do it for current scroll marker as well
<kbabbitt> schenney: what did we choose?
<kbabbitt> TabAtkins: target-current I believe
<kbabbitt> fantasai: webvtt pseudo classes are heavily used
<astearns> ack fantasai
<kbabbitt> ... don't think we can change
<kbabbitt> ... in lots of content from what I understand\
<kbabbitt> ... re: not having concept of past and ufutre, that's not ture
<kbabbitt> ... there's an ordering in search results, you have next and previous and taht corresponds to past and future
<kbabbitt> ... we could define past and future to be applicable ot search text
<kbabbitt> ... past is result looked at already backward in chain
<kbabbitt> ... future is going forward
<kbabbitt> ... whether we want to impl that is separate question
<kbabbitt> TabAtkins: there's still thet ancestor mismatch
<kbabbitt> ... current past and future apply to element and ancestors
<kbabbitt> fantasai: but we're in a pseudo tree so that's okay
<astearns> ack florian
<kbabbitt> florian: assuming we don't rename to something else
<kbabbitt> ... and because it seems like we could define them to mean something
<kbabbitt> ... I think we should fail at parse time so you can @supports detect
<kbabbitt> ... if it doesn't do anything you can detecty
<kbabbitt> ...then one day when we want to make them do something they start existing
<kbabbitt> TabAtkins: that would be better, yes
<TabAtkins> agree if we don't rename, it shoudl fail to parse
<florian> s/define them/define past and future
<kbabbitt> fantasai: not 100% convinced we should use a pseudo class here
<kbabbitt> ... but if we are, past and future are perfectly sensible in this context
<fantasai> s/,/ current,/
<kbabbitt> astearns: for this issue, resolution would be to make past and future invalid for now?
<kbabbitt> RESOLVED: Make :past and :future invalid for now, to reserve them for future use
<kbabbitt> schenney: is the functional form of current also invalid? I propose that it is
<kbabbitt> TabAtkins: other than we should rename it instead, yes
<kbabbitt> Proposed: Make the functional form of :current also invalid for highlight pseudos
<kbabbitt> RESOLVED: Make the functional form of :current also invalid for highlight pseudos
<kbabbitt> schenney: the current language is like is but it isn't like is
<kbabbitt> TabAtkins: fixup to match intention in spec
<kbabbitt> ... I'll do it