#348: TAG review of whether element.pseudo(":unknown") should return null or throw
Discussions
Comment by @dbaron Mar 29, 2019 (See Github)
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:
- the implementation supports a pseudo-element with this name/syntax, but not on this element
- the implementation doesn't support a pseudo-element with this name/syntax
- 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.
Comment by @annevk Mar 31, 2019 (See Github)
When would 1 apply?
Comment by @dbaron Mar 31, 2019 (See Github)
One example might be ::marker, which only exists on elements that are display: list-item.
Comment by @annevk Apr 1, 2019 (See Github)
Does that mean that this might become another "forces layout" API without that being documented in detail?
Comment by @dbaron Apr 1, 2019 (See Github)
That's a good argument for not doing anything based on (1).
Discussed
Apr 17, 2019 (See Github)
Tess: CSS will be disucssing this tonight
David: I think this is pointing out a gap in the design principles doc... we ought to be able to document how people make this sort of decision so people do it with some sort of consistency. I'll open an issue on that doc.
Peter: We've been down this road before on the design principles
Sanghwan: and we never actually fix the document
Peter: I know CSS WG have done this before...
David: You're right, it's issue 55 that is closest to this. I'll link to it.
Torgo: Is there a link to the CSS Agenda?
David: https://lists.w3.org/Archives/Public/www-style/2019Apr/0012.html
Torgo: MIlestone for next wee
Comment by @torgo Apr 17, 2019 (See Github)
We discussed briefly today in TAG call - and agreed to review pending the CSS wg discussion.
Discussed
May 8, 2019 (See Github)
Tess: last time we talked about this was before a CSS call.
Peter: this wasn't discussed on the [CSS] call.
David: [nobody] really cared about this detail.
Alice: in the linked CSS wd draft issue they said they resolved null and asked us. Null seems fine to me. David saw your proposal about undefined but don't know about that.
Alice: i think our opinion is "not an exception"
Dan: can we close this?
Tess: sounds like we can to me - unless anyone has strong feelings.
Peter: i'm ok with it returning Null. Meta question: do we have advice in our API design guidelines for this sort of thing.
Tess: can we close this issue and open up a design guidelines issue?
Alice: already have an issue - that david referenced in that review.
Tess: I'll comment on it and close it.
[woot!
Comment by @hober May 8, 2019 (See Github)
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 https://github.com/w3ctag/design-principles/issues/55
OpenedFeb 25, 2019
こんにちはTAG！
I'm requesting a TAG review of:
We'd prefer the TAG provide feedback by commenting in this issue (for comments relevant to that issue) https://github.com/w3c/csswg-drafts/issues/3603 or by opening new issues if more issues are found.