Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect statement about pseudo-elements needing to come last in a selector #32971

Open
m-akinc opened this issue Apr 5, 2024 · 7 comments
Open
Labels
Content:CSS Cascading Style Sheets docs goal: accuracy (Experimental label) Issues about inaccurate/incorrect content. help wanted If you know something about this topic, we would love your help!

Comments

@m-akinc
Copy link

m-akinc commented Apr 5, 2024

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements

What specific section or headline is this issue about?

Syntax

What information was incorrect, unhelpful, or incomplete?

The pseudo-element must appear after all the other components in the complex or compound selector in which it appears. For example, you can select a paragraph's first line using p::first-line but not the first-line's children or a hovered first line. So both p::first-line > * and p::first-line:hover are invalid.

This is not true for all pseudo-elements. ::part() supports appending pseudo-classes like :hover. This is even shown in the ::part documentation examples. I'm not sure if there are other pseudo-elements besides ::part() that support this.

What did you expect to see?

At least call out any exceptions (like ::part():hover).

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Page report details
@m-akinc m-akinc added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Apr 5, 2024
@github-actions github-actions bot added the Content:CSS Cascading Style Sheets docs label Apr 5, 2024
@Josh-Cena Josh-Cena added help wanted If you know something about this topic, we would love your help! goal: accuracy (Experimental label) Issues about inaccurate/incorrect content. and removed needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. labels Jun 5, 2024
@Josh-Cena
Copy link
Member

Josh-Cena commented Jun 11, 2024

See spec:

Certain pseudo-elements may be immediately followed by any combination of certain pseudo-classes, in which case the pseudo-element is represented only when it is in the corresponding state. This specification allows any pseudo-element to be followed by any combination of the logical combination pseudo-classes and the user action pseudo-classes. Other specifications may allow additional pseudo-classes to be attached to particular pseudo-elements. Combinations that are not explicitly allowed are invalid selectors.

NOTE: The logical combination pseudo-classes pass any restrictions on validity of selectors at their position to their arguments.

For example, since the :hover pseudo-class specifies that it can apply to any pseudo-element, ::first-line:hover will match when the first line is hovered. However, since neither :focus nor ::first-line define that :focus can apply to ::first-line, the selector ::first-line:focus will never match anything.
Notice that ::first-line:hover is very different from :hover::first-line, which matches the first line of any originating element that is hovered! For example, :hover::first-line also matches the first line of a paragraph when the second line of the paragraph is hovered, whereas ::first-line:hover only matches if the first line itself is hovered.

So it seems that p::first-line:hover is already valid.

@m-akinc
Copy link
Author

m-akinc commented Jun 11, 2024

So it seems that p::first-line:hover is already valid.

Yes, it turns out the MDN doc directly contradicts the spec.

@estelle
Copy link
Member

estelle commented Jun 12, 2024

So it seems that p::first-line:hover is already valid.

tested. invalid. The entire block fails in FF, Safari, Edge (and other chromium browsers).

See https://codepen.io/estelle/pen/WNBXQNg

I think we need to file a query / issue with the spec.

@Josh-Cena
Copy link
Member

Josh-Cena commented Jun 12, 2024

It's possible that none of the browsers implement this yet. The last issue I can find is w3c/csswg-drafts#7085, which points me to https://bugzilla.mozilla.org/show_bug.cgi?id=1122965.

@m-akinc
Copy link
Author

m-akinc commented Jun 12, 2024

tested. invalid. The entire block fails in FF, Safari, Edge (and other chromium browsers).

So at the moment, the documentation is correct that p::first-line:hover is invalid, but it is still incorrect that "The pseudo-element must appear after all the other components in the complex or compound selector in which it appears." p::part(foo):hover is valid (checked FF and Chrome). So at least ::part() supports appending pseudo-classes.

@estelle
Copy link
Member

estelle commented Jun 12, 2024

It appears that allowing pseudo classes and forgiving selector lists after pseudo elements was addressed in 2022. w3c/csswg-drafts#7085 (comment) but the ::firstline:hover was already in the spec in 2018 - (see https://www.w3.org/TR/2018/WD-selectors-4-20181121/#pseudo-element-states for the exact same example) so seems like it's a browser bug, and we need to update the text saying it's allowed per the spec, but only supported in X cases. Not sure what X is yet.

Even if a browser does support ::first-line:hover, they should at least ignore it, as it's valid and just not supported, but there's a line in the browser code that make it fail, not just ignore.

@estelle
Copy link
Member

estelle commented Jun 12, 2024

So at the moment, the documentation is correct that p::first-line:hover is invalid, but it is still incorrect that "The pseudo-element must appear after all the other components in the complex or compound selector in which it appears." p::part(foo):hover is valid (checked FF and Chrome). So at least ::part() supports appending pseudo-classes.

Yes. Unfortunately, this isn't the simple edit that I thought it would be. We can't just remove "not supported", we have to figure out which pseudo elements support the spec and which don't. It would also be helpful to have a timeline of intended support. Like, is it part of baseline?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:CSS Cascading Style Sheets docs goal: accuracy (Experimental label) Issues about inaccurate/incorrect content. help wanted If you know something about this topic, we would love your help!
3 participants