So I think one question here is to what extent we should be looking for analogous cases that are functions, and to what extent we should be looking at analogous cases that are attributes. I ask this because .pseudo() is rather like attributes, except that it's large space of attributes and you're saying which one you want by giving the argument to the function.

It seems like there are three possible options for what to do when there isn't an object to return: null, undefined, or an exception. There are also multiple cases of not having an object, which could deserve different treatment:

1. the implementation supports a pseudo-element with this name/syntax, but not on this element
2. the implementation doesn't support a pseudo-element with this name/syntax
3. the string argument given doesn't appear to be the syntax of a pseudo-element

I think distinguishing between (2) and (3) is a bad idea because it could make future syntax expansion difficult. But there might be a bit more reason for (1) to be different.

If you think of these like attributes, then it might make sense for (1) to be null and (2) and (3) to be undefined... but at the same time, I think it's highly unusual for web APIs to return undefined.

I'm having trouble thinking of closer analogies currently within the platform, though.

When would 1 apply?

One example might be ::marker, which only exists on elements that are display: list-item.

Does that mean that this might become another "forces layout" API without that being documented in detail?

That's a good argument for not doing anything based on (1).

We discussed briefly today in TAG call - and agreed to review pending the CSS wg discussion.

We discussed this on our telcon tonight. We think returning null is reasonable. We'll update our design guidelines to cover cases like this; that work is tracked in w3ctag/design-principles#55