[selectors-4] Move to CR?

@fantasai

Given the huge list of features that are seem to be ready to release, I wonder whether we should try to get Selectors 4 in shape for moving to Candidate Recommendation status.

To do that, I suggest moving the following features to level 5 of the spec. and feature-freeze level 4:

:local-link (already there, though needs to be removed from level 4)
:interest-source and :interest-target
:blank
All grid-structural selectors, i.e. the || combinator, :nth-col(), and :nth-last-col()
All time-dimensional pseudo-classes , i.e. :current, :current(), :past, and :future

@fantasai @tabatkins What's your opinion?

Sebastian

Stabilizing and feature-freezing seems like a good plan. Then:

Update (and trim, for removed features) the changes section
Add an (empty) Security Considerations
Add WPT annotations for the relevant tests
Republish a WD
Get horizontal review
Republish WD including changes from horizontal review
Triage not-for this-level issues
Request CR

I am in favor of this plan. Pushing Selectors 4 to CR is long overdue.

Are we proposing to defer :current(), :current() and :current, or all time-dimensional pseudo-classes?

:past and :future already seem to be implemented in Chrome, Edge, Safari while :current (and :current()) is not, according to MDN. There are no WPTs to verify that, though.

Anyway, I wouldn't have a problem to defer all time-dimensional pseudo-classes if that helps avoiding controversies.

Sebastian

FWIW, WebKit implements the resource state pseudo classes, so we may want to keep them if they are not riddled with issues.

@fantasai

@fantasai Fine, I've removed the resource state pseudo classes from the list.

Adding Agenda+ to resolve on which features are moved to level 5 and to publish a new WD once the changes are done.

Sebastian

@fantasai

Given @fantasai, as an editor, is positive about this, I think it's fine to resolve this asynchonously.
Note that I added all time-dimensional pseudo-classes to the list of features to be deferred.

So the proposed resolution is:

Move the features listed in the first comment to Selectors 5
Publish a new WD and get horizontal review

Sebastian

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: Move listed features from Selectors level 4 to level 5, republish level 4 and get horizontal review on the way to CR.

Agenda+ to get agreement (as I am not an editor) to publish a WD of Selectors 4, which incorporates clarifications from Horizontal review.

Changes since the Jan 2026 WD

(whoops, wrong button lol)

@fantasai

@fantasai @tabatkins is it okay to publish?

Reviewing the changes:

I don't think I was present for [css-syntax-3] The + in <an+b> confuses parsing tools #9473 because I think I disagree with the resolution... would have preferred something more readable and easier to type, several options were suggested earlier in the issue but weren't mentioned in the minutes at all.
It looks like this commit clarified some things but also made the first paragraph more confusing, would be good to improve that.
This change lost the point that you can match invalid language tags, as long as they're well-formed. Was that intentional?
This change makes me wonder what impact the change in wording has wrt validity requirements for selector parsing, and if that changes them.

The CSS Working Group just discussed [selectors-4] Move to CR?.

The full IRC log of that discussion

<kbabbitt> ChrisL: we have generall agreement from this group to push this to CR
<kbabbitt> ... I put into horizontal review, all are in except security
<kbabbitt> ... also wrote an explainer, there were some changes from i18n, I'd like to publish an updated WD with those changes
<kbabbitt> ... with an eye towards taking to CR once we know which things need to be fixed
<kbabbitt> ... but none of that precludes an updated WD
<kbabbitt> fantasai: I reviewed the changes since previous publication
<kbabbitt> ... couple points where we made things better but others we might have regressed something
<kbabbitt> ... an+b stuff, was surprised at the resolution
<kbabbitt> ChrisL: don't understand that part, TabAtkins did it
<TabAtkins> Let me see what elika is confused about wrt an-b...
<kbabbitt> fantasai: there's a difference between does it match and does it parse, have to be careful about what we end up treating as invalid and invalidating whole selector
<kbabbitt> ... something I would like to double-check before we publish
<kbabbitt> ChrisL: ok will need re-sign-off from reviewers
<kbabbitt> ... sorry if I overstepped, went ahead with wide review
<kbabbitt> fantasai: appreciate you did that, should have reviewed changes
<kbabbitt> astearns: next round of wide review should be easier since it will be a smaller set of changes
<kbabbitt> ... fantasai, you want to look at some issues before we publish? or could we publish. now with idea that we'll publish again after looking?
<kbabbitt> fantasai: I suspect it will not take more than a week to circle through this, largely just some tweaks
<kbabbitt> ... if there's an actual problem I'll bring it back up with WG
<kbabbitt> ... we could resolve to publish pending a few editorial changes
<kbabbitt> ... I do have a question about the an+b discussion, not sure how I missed that, but I don't particularly like the thing we settled on, it's awkward
<kbabbitt> ... were people really rejecting the other options?
<emilio> q+
<kbabbitt> astearns: since the an+b thing wasn't on the agenda, could you raise an issue for it?
<kbabbitt> ChrisL: that was a change on syntax-3, not selectors
<kbabbitt> ... selectors was updated to point to that
<TabAtkins> It was a low-impact discussion, nobody had big opinions on it, there was weak desire for a-n-plus-b
<kbabbitt> emilio: is the an+b thing even normative?
<kbabbitt> fantasai: it's not normative but also has syntax-3 been updated? it won't link otherwise
<TabAtkins> not republished, but yes https://drafts.csswg.org/css-syntax/#the-anb-type is fine
<kbabbitt> ... will reopen that issue, we should not republish until syntax-3 is updated
<kbabbitt> ChrisL: fair
<kbabbitt> astearns: we'll come back to these soon

Also it seems like we should republish css-syntax-3 before selectors-4, or else the an+b changes won't link over properly anymore.

@aphillips

This change lost the point that you can match invalid language tags, as long as they're well-formed. Was that intentional?

Yes. @aphillips said

We can forbid non-valid tags/ranges from ever matching. The text for that might be:

The element’s content language matches a language range if its content language, as represented in BCP 47 syntax, matches the given language range in an extended filtering operation per [RFC4647] Matching of Language Tags (section 3.3.2). The content language and the language range must be canonicalized and converted to extlang form as per section 4.5 of [RFC5646] prior to the extended filtering operation; language tags or ranges that are not valid do not match anything. The matching is performed ASCII case-insensitively.

Also it seems like we should republish css-syntax-3 before selectors-4, or else the an+b changes won't link over properly anymore.

Okay. Looking at the edit history, the changes section is not up to date.

The normative references checker flags several maybe-normative things including Syntax 3

Okay. Looking at the edit history, the changes section is not up to date.

I brought the changes section in Syntax 3 up to date. Can we publish it ,so we stop blocking Selectors 4 publication?

This change makes me wonder what impact the change in wording has wrt validity requirements for selector parsing, and if that changes them.

See

[selectors-4] language-range is missing its definition #13646

Navigation Menu

Repository navigation

[selectors-4] Move to CR? #12799

23 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[selectors-4] Move to CR? #12799

Description

Activity

svgeesus commented on Sep 15, 2025

fantasai commented on Sep 15, 2025

SebastianZ commented on Sep 15, 2025

fantasai commented on Sep 16, 2025

SebastianZ commented on Oct 17, 2025

SebastianZ commented on Nov 25, 2025

astearns commented on Dec 1, 2025

23 remaining items

svgeesus commented on Jul 21, 2026

svgeesus commented on Jul 21, 2026

svgeesus commented on Jul 21, 2026

fantasai commented on Jul 22, 2026

css-meeting-bot commented on Jul 22, 2026

fantasai commented on Jul 22, 2026

svgeesus commented on Jul 22, 2026

svgeesus commented on Jul 22, 2026

svgeesus commented on Jul 22, 2026

svgeesus commented on Jul 30, 2026

svgeesus commented on Jul 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions