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: 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`

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


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

Received on Wednesday, 29 January 2025 22:27:33 UTC