Re: [csswg-drafts] What should `pseudo(type)` return for elements that can't have pseudo elements? (#12159)

The CSS Working Group just discussed ``What should `pseudo(type)` return for elements that can't have pseudo elements?``, and agreed to the following:

* `RESOLVED: proposed: for a valid selector we will always return the CSSPseudoElement object`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> sakhapov: this one is about entry point element.pseudo which always returns element if selector is valid<br>
&lt;flackr> q+<br>
&lt;ydaniv> ... for example input element can not generate pseudos, so question what to return in this case<br>
&lt;ydaniv> ... false or otherwise<br>
&lt;ydaniv> ... no preference here, looking for ideas<br>
&lt;astearns> ack flackr<br>
&lt;ydaniv> flackr: one clarification, if selector is invalid, does it throw?<br>
&lt;ydaniv> sakhapov: I think we return null<br>
&lt;ydaniv> flackr: I think in other APIs we throw, so should consider changing<br>
&lt;ydaniv> ... I think if the pseudo could conditionally exist then should be good to return an interface of whether it exists<br>
&lt;kbabbitt> q+<br>
&lt;ydaniv> ... might be other cases where existence could change<br>
&lt;ydaniv> sakhapov: if wanna add scroll event listeners to scroll-marker then enter a loop and just request scroll-marker on every element, and then exceptions would look ugly<br>
&lt;ydaniv> flackr: if the selector that you wrote is never valid we should throw<br>
&lt;ydaniv> sakhapov: question if we should throw on before/after<br>
&lt;ydaniv> flackr: in that case condition can't change<br>
&lt;TabAtkins> q+<br>
&lt;astearns> ack kbabbitt<br>
&lt;ydaniv> kbabbitt: just thinking on Rob's point, gets weird in some cases, for example with checkboxes, can change the state and get different pseudo, kind of weird<br>
&lt;ydaniv> sakhapov: in this scenario defined to always return<br>
&lt;astearns> ack TabAtkins<br>
&lt;ydaniv> ... we can discuss back in the issue<br>
&lt;ydaniv> TabAtkins: on Rob's point, the condition of existence, isn't necessarily a static thing, like password reveal icon<br>
&lt;ydaniv> ... definitely don't want a throw to happen<br>
&lt;ydaniv> ... I think "knowing" is definitly helpful<br>
&lt;ydaniv> flackr: was only advocating to cases to throw if not valid<br>
&lt;flackr> similar to element.animate: https://www.w3.org/TR/web-animations-1/#dom-keyframeeffect-pseudoelement<br>
&lt;ydaniv> TabAtkins: ok<br>
&lt;kbabbitt> I think querySelector throws on an invalid selector also<br>
&lt;ydaniv> sakhapov: for now returns null when not valid<br>
&lt;ydaniv> TabAtkins: if at all possible throwing on non-valid stuff is ideal<br>
&lt;ydaniv> ... there's a chance it's not web compat<br>
&lt;ydaniv> ... but should be silent if valid but not getting anything right now<br>
&lt;ydaniv> sakhapov: but then in cases you get null and change type of element then you once again call for same pseudo, but then you query again you get an element<br>
&lt;kbabbitt> q+<br>
&lt;ydaniv> ... is that stable?<br>
&lt;ydaniv> TabAtkins: if your input goes to password and back, if you queried on all states you get the first option first and last should be same<br>
&lt;TabAtkins> TabAtkins: if you change an input from password, to text, then back to password, and ask for a password-reveal pseudo-element all three states, you should get the same object back on the first and third calls, ideally (despite getting null on the second call)<br>
&lt;TabAtkins> TabAtkins: And that should be addressable with `[SameObject]` and some prose, I think<br>
&lt;ydaniv> kbabbitt: kind of related, for password control, grab a pseudo element for that, and then change input type to text where pseudo doesn't exist, and query, not clear what behavior should be<br>
&lt;flackr> q+<br>
&lt;ydaniv> TabAtkins: I'd assume that when they don't exist it would reveal the change<br>
&lt;TabAtkins> s/the change/the change via the "exists" boolean/<br>
&lt;ydaniv> kbabbitt: in that case, does the null return makes sense? how is it different than returning object and checking for existence?<br>
&lt;ydaniv> TabAtkins: if you know at time of call it doesn't exist returning something that may change is bad design<br>
&lt;astearns> ack kbabbitt<br>
&lt;ydaniv> ... I think in common case if you're not changing things around, it's more useful to get no result back if doesn't exist ATM<br>
&lt;ydaniv> kbabbitt: going to previous issue should be good to have use-cases<br>
&lt;astearns> ack flackr<br>
&lt;ydaniv> flackr: I feel I'm on the other side, there's a pref cost on checking for existence, having event listeners and style resolution<br>
&lt;ydaniv> ... we'd like developers to be able to set stuff up if they're not in the documnet<br>
&lt;ydaniv> astearns: Rob convinced me<br>
&lt;TabAtkins> +1 to resolve on always returning a pseudoelement, yeah<br>
&lt;ydaniv> proposed: for a valid selector we will always return the CSSPseudoSelector object<br>
&lt;sakhapov> CSSPseudoElement object<br>
&lt;ydaniv> proposed: for a valid selector we will always return the CSSPseudoElement object<br>
&lt;ydaniv> ... objections?<br>
&lt;ydaniv> RESOLVED: proposed: for a valid selector we will always return the CSSPseudoElement object<br>
&lt;TabAtkins> ScribeNick: TabAtkins<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12159#issuecomment-3005238286 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 June 2025 15:39:04 UTC