I guess leaving out the change to the individual hN selectors makes sense. We can make that change to the UA style sheet as part of the new attributes, as until then it wouldn't really be an improvement.

I'm double checking whether WebKit is interested, but I suspect so.

@fantasai pointed out to me that in w3c/csswg-drafts#10296 (comment) there was discussion about a different specificity for these pseudo-classes, but this does not appear to be reflected in the changes to the Selectors specification, despite claims back in April that it would be. Can someone clarify this for me?

[...] specificity for these pseudo-classes [...]

The spec states: https://drafts.csswg.org/selectors-5/#headings

The specificity of :heading() is that of a class.

This was updated in w3c/csswg-drafts#12404 which while not updated in April as claimed, was updated today!

AIUI this is per the resolution in w3c/csswg-drafts#10296 (comment).

RESOLVED: :heading() has the expected class-level specificity

You can consider WebKit supportive of adding these. @LeaVerou since you commented on the CSS issue regarding specificity, any final thoughts from you?

I still don't have a strong opinion, I can see arguments for both class-level specificity and tag-level specificity.
Some reservations around ARIA heading roles not affecting this, especially since it means there is no way for web components to hook into it.
Also, just to make sure, presumably <h1 aria-level="2"> would match :heading(2) and not :heading(1), right?

Aria would always supersede. Consequently :heading(1), [role=heading][aria-level=1] would match the equivalent levels.

<h1 aria-level=2> would match :heading(1). Aria mustn’t influence CSS in that way. One can use the attribute selector mentioned above and ensure a good cascade order to circumvent any potential issues.

I wrote more about this over in w3c/csswg-drafts#12412 (comment) which hopefully details some of why it is untenable for :heading to match. Perhaps that's also a more fruitful place for discussion than this PR?

Indeed, long ago we have settled on ARIA not influencing semantics. It's an expert tool that solely influences AT. (This does mean that :heading(1) could match the same thing as [aria-level=2], but this would also be highly indicative of an authoring error.)

(This does mean that :heading(1) could match the same thing as [aria-level=2], but this would also be highly indicative of an authoring error.)

Re:authoring error, I think there are valid use cases for overriding heading level via aria-level. Polyfilling headingoffset for one :) Back in the days of the old HTML5 outline algorithm, I've been meaning to write a polyfill for it that worked by adding aria-level attributes, and just never got around to it.

That's why I wrote highly indicative and not that it's set in stone. 😊