TAG review of whether element.pseudo(":unknown") should return null or throw

[fantasai]

こんにちはTAG！

I'm requesting a TAG review of:

• Name: element.pseudo() return values / errors
• Specification URL: https://www.w3.org/TR/css-pseudo-4/#window-interface && https://drafts.csswg.org/css-pseudo-4/
• Explainer, Requirements Doc, or Example code: [css-pseudo-4] Should Element.pseudo("unknown") be an error or return null? w3c/csswg-drafts#3603
• Primary contacts: @fantasai
• Current status: CSSWG is currently planning to spec always returning the object if the pseudo-element type is supported and always returning null if it's not, but wants to ask for the TAG's review to make sure the element.pseudo() pattern is consistent with the rest of the platform.

We'd prefer the TAG provide feedback by commenting in this issue (for comments relevant to that issue) w3c/csswg-drafts#3603 or by opening new issues if more issues are found.

[dbaron]

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.

[annevk]

When would 1 apply?

[dbaron]

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

[annevk]

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

[dbaron]

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

[torgo]

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

[hober]

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