Treating it as non-existent sounds good. So that would mean returning null per the current spec. But if my second paragraph last sentence question in #3541 (comment) is reasonable, we would could return a (mostly useless) CSSPseudoElement object here too.

+1 null (because qSA throwing errors is very very very annoying)

Compare:

if(document.body.pseudo("backdrop")) {
    // ... 
}

vs

var isBackdropSupported = true; try { document.body.pseudo("backdrop") } catch (ex) { isBackdropSupported = false; }
if(isBackdropSupported) {
    // ...
}

The CSS Working Group just discussed Should Element.pseudo("unknown") be an error or return null?.

(In issue #3540 we marked support for non-before/after pseudos at-risk of being removed from the spec; if we do so, this function won't be useful as a detection mechanism anyway, and we need to decide what to do for first-line etc; should they really throw?)

I'm cool with returning null here. As François says, there's value in doing simple tests to see if a pseudo is supported at all. If you actually try to use it, null will quickly throw an error anyway. (null.style throws immediately)

The CSS Working Group just discussed unknown pseudo() arg, and agreed to the following:

• RESOLVED: Return null provisionally and open a TAG review issue.

I'd expect an exception if it doesn't meet the syntactic requirements for a pseudo-element. However, I guess that only really works if pseudo-elements won't gain arguments. Because at that point it's ambiguous whether before(...) meets the constraints or not.

It's somewhat confusing though that this issue uses "unknown" and the TAG review issue uses ":unknown". Does "before" work? Does ":before"? Does "::before"? Is there a formal definition of this method somewhere?

@annevk I think the simplest thing would be if the value isn't a string in the valid types list, it's an error. (Atm the spec just returns null for all type errors.) Agenda+ in case anyone thinks we should be doing something else.

@fantasai so :before and ::before are errors? And a pseudo-element that takes an argument would also be an error if you pass in pseudo-with-argument(some-valid-argument)?

The latter seems problematic for the ::part pseudo-element, where you probably want to return different objects depending on the argument passed to the pseudo-element.

@annevk ::before would be valid. :before would be invalid. If we later allow ::part() then we'll have to define what gets returned for the various arguments to it; currently it's invalid because not supported.

So if you use pseudo-element syntax and not pseudo-element identifiers, would ::\42 efore work too? It seems a lot simpler to only accept identifiers, though with pseudo-elements accepting arguments it might have to get more involved somehow (likely the method would have to take multiple arguments too).

Accepting "identifiers" would mean that \42 efore would work too. ^_^ Presume you mean literal matches against a defined list of strings, tho.

Having to later map pseudo-element arguments into JS arguments really makes it feel like this is trying to draw a distinction that's not worth it? Like, I'm mostly for not invoking the CSS parser when not necessary, but it seems like it'll actually get some use here.

Right, sorry. I see some kind of rough analogy to Houdini. That is, do you want to program with CSS/Selectors-like strings, or do you want to program against the underlying data model? It seems to me that per https://extensiblewebmanifesto.org/ but also some other principles (separation of concerns comes to mind) you want to provide an API for the underlying model.

Sure, but don't apply that too naively. We're not exposing a reified "pseudo-element query" object that, when resolved against an Element, returns a PseudoElement. We def don't intend to require you to construct CSSKeywordValue/etc objects to pass over to it. It's not a fully TypedOM-ified API, and isn't intended to be, as that would just be busywork for no benefit. (The object forms exist to make it easier to read/alter things from JS; they're harder to write from JS than strings are. This is a write-only API.)

Turning .pseudo("::foo(bar, baz)") into .pseudo("foo", "bar", "baz") is similarly just busywork making it harder to read/write and connect to the stylesheet syntax

Well, at some point someone will have to make that translation and define what it means. (E.g., whether argument-accepting pseudo-elements can return different PSeudoElement objects or whether that depends.)

They'll return different objects if the arguments cause the calls to refer to different pseudo-elements, sure. If they resolve to the same pseudo they'll return the same object. "Same" here means whether styles applied with the two selectors cascade together or not.

(Moot right now due to the limited list, of course.)

Not sure how that eventual clarification is relevant to the syntax argument, tho. That question needs answering regardless of how you write the JS method.

So, to answer the overall question:

We should do a [=CSS/parse=] on the string, matching it against the grammars of the allowed pseudo-elements.

Although that makes me wonder about the pseudo argument of getComputedStyle, and whether it should change to do a [=CSS/parse=]...

The CSS Working Group just discussed Should Element.pseudo("unknown") be an error or return null?, and agreed to the following:

• RESOLVED: Do a css parse on parameter for element.pseudo()

It seems the CSS WG discussion didn't touch upon @heycam's point, which is quite relevant.

gCS() should indeed switch to [=CSS/parse=]; its current definition isn't well-founded, as there's no notion of a string "matching" a CSS construct by itself. (You need to parse it.)

And that issue got filed as #3875.