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

[selectors-4] x-pseudo-element test is not documented in the selectors-4 spec #6826

Closed
jwmcglynn opened this issue Nov 23, 2021 · 6 comments
Closed

Comments

@jwmcglynn
Copy link

jwmcglynn commented Nov 23, 2021

web-platform-tests/wpt#12743 created a test with the description of "x-prefixed pseudo-elements should make the whole rule invalid".

It's attached to Section 3.6 Pseudo elements (see test table), however looking at the draft version of the spec, that behavior is not documented. In fact, the only time "x-" appears in the entire spec is for within the words "complex-" or "max-".

It looks like the spec needs to be updated, however as an aside I'd like to mention that this change seems a bit weird. Looking at the pull request that added the test and the attached webkit bug, I don't see any discussion about why the behavior was added. Adding context would be helpful, since this seems like something that could be considered a breaking change for some parsers.

For context, here is the type of selector this test asserts to be invalid:

::x-something-nobody-would-think-of, p {
  color: red;
}

Slightly later in the spec, in 3.9 Invalid Selectors and Error Handling, it states that "a selector list containing an invalid selector is invalid", however in 3.6 there is a line stating that "The host language defines which pseudo-elements exist".

This makes sense, I saw discussion in another bug about how "::-webkit"-prefixed pseudo elements are only supported on webkit and invalidate the whole selector on other UAs. I think the wording can be improved by updating the text to say something along the lines of

The host language and UAs defines which pseudo-elements exist [...]. If a pseudo-element does not exist, the selector is invalid.

...

UAs must not implement support for pseudo-elements prefixed with x-, such as ::x-pseudo-element.

Now that I'm writing that, my expectation of that is actually the opposite. For HTTP headers prefixing them with "X-" makes them ignored by the UA, so that it may be used for custom metadata and consumed by scripts. Maybe the ::x- pseudo prefix could operate the same way, providing a mechanism for user-defined pseudo elements?

If I missed something please let me know, but I spent the last hour or two scouring so if it is documented. It was not discoverable for me and may be a reason to amend the spec 🙂

@Loirooriol
Copy link
Contributor

There is nothing special about ::x-something-nobody-would-think-of, it's invalid just like ::something-nobody-would-think-of.

The test checks ::x- specifically, because WebKit used to treat that as valid. https://bugs.webkit.org/show_bug.cgi?id=189089

I saw discussion in another bug about how "::-webkit"-prefixed pseudo elements are only supported on webkit and invalidate the whole selector on other UAs

#3051 (comment) resolved that all ::-webkit- pseudos are valid.

Maybe the ::x- pseudo prefix could operate the same way, providing a mechanism for user-defined pseudo elements?

Author-defined pseudo-elements should probably use ::--.

@jwmcglynn
Copy link
Author

Ah, that makes sense, ::x- is to specifically validate that WebKit doesn't treat it as valid, the name itself is weird enough that other UAs shouldn't use it. Thanks for the clarification.

Author-defined pseudo-elements should probably use ::--.

Yeah, that makes sense as well and is consistent with the <ident-token> handling.

With this information, I would still recommend my first paragraph suggestion:

The host language and UAs defines which pseudo-elements exist [...]. If a pseudo-element does not exist, the selector is invalid.

@Loirooriol Loirooriol added the selectors-4 Current Work label Nov 25, 2021
@tabatkins
Copy link
Member

That's already stated in the general section on selector validity https://drafts.csswg.org/selectors/#invalid.

@Loirooriol
Copy link
Contributor

@tabatkins I thought the same, but which point actually covers unknown pseudo-elements? It's not an invalid token according to the grammar, and pseudo-elements aren't a simple selectors according to https://drafts.csswg.org/selectors/#simple

@tabatkins
Copy link
Member

You'll notice that, technically, pseudo-elements don't show up in any of those categories, because pseudo-elements are implemented as an awful grammatical hack that breaks a lot of assumptions in the data model.

The intention is that it's a simple selector (with some extra complications). I should see if I can fix up that text to say so; in the meantime, tho, we don't need any additional text specifically calling out pseudo-elements elsewhere.

@Loirooriol
Copy link
Contributor

Then, if you don't fix it completely, at least replace

ISSUE 1: Pseudo-elements aren’t handled here, and should be.

with something like

ISSUE 1: Pseudo-elements should be handled here as simple selectors with some extra complications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants