- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 25 Jun 2025 15:39:03 +0000
- To: public-css-archive@w3.org
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> <ydaniv> sakhapov: this one is about entry point element.pseudo which always returns element if selector is valid<br> <flackr> q+<br> <ydaniv> ... for example input element can not generate pseudos, so question what to return in this case<br> <ydaniv> ... false or otherwise<br> <ydaniv> ... no preference here, looking for ideas<br> <astearns> ack flackr<br> <ydaniv> flackr: one clarification, if selector is invalid, does it throw?<br> <ydaniv> sakhapov: I think we return null<br> <ydaniv> flackr: I think in other APIs we throw, so should consider changing<br> <ydaniv> ... I think if the pseudo could conditionally exist then should be good to return an interface of whether it exists<br> <kbabbitt> q+<br> <ydaniv> ... might be other cases where existence could change<br> <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> <ydaniv> flackr: if the selector that you wrote is never valid we should throw<br> <ydaniv> sakhapov: question if we should throw on before/after<br> <ydaniv> flackr: in that case condition can't change<br> <TabAtkins> q+<br> <astearns> ack kbabbitt<br> <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> <ydaniv> sakhapov: in this scenario defined to always return<br> <astearns> ack TabAtkins<br> <ydaniv> ... we can discuss back in the issue<br> <ydaniv> TabAtkins: on Rob's point, the condition of existence, isn't necessarily a static thing, like password reveal icon<br> <ydaniv> ... definitely don't want a throw to happen<br> <ydaniv> ... I think "knowing" is definitly helpful<br> <ydaniv> flackr: was only advocating to cases to throw if not valid<br> <flackr> similar to element.animate: https://www.w3.org/TR/web-animations-1/#dom-keyframeeffect-pseudoelement<br> <ydaniv> TabAtkins: ok<br> <kbabbitt> I think querySelector throws on an invalid selector also<br> <ydaniv> sakhapov: for now returns null when not valid<br> <ydaniv> TabAtkins: if at all possible throwing on non-valid stuff is ideal<br> <ydaniv> ... there's a chance it's not web compat<br> <ydaniv> ... but should be silent if valid but not getting anything right now<br> <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> <kbabbitt> q+<br> <ydaniv> ... is that stable?<br> <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> <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> <TabAtkins> TabAtkins: And that should be addressable with `[SameObject]` and some prose, I think<br> <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> <flackr> q+<br> <ydaniv> TabAtkins: I'd assume that when they don't exist it would reveal the change<br> <TabAtkins> s/the change/the change via the "exists" boolean/<br> <ydaniv> kbabbitt: in that case, does the null return makes sense? how is it different than returning object and checking for existence?<br> <ydaniv> TabAtkins: if you know at time of call it doesn't exist returning something that may change is bad design<br> <astearns> ack kbabbitt<br> <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> <ydaniv> kbabbitt: going to previous issue should be good to have use-cases<br> <astearns> ack flackr<br> <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> <ydaniv> ... we'd like developers to be able to set stuff up if they're not in the documnet<br> <ydaniv> astearns: Rob convinced me<br> <TabAtkins> +1 to resolve on always returning a pseudoelement, yeah<br> <ydaniv> proposed: for a valid selector we will always return the CSSPseudoSelector object<br> <sakhapov> CSSPseudoElement object<br> <ydaniv> proposed: for a valid selector we will always return the CSSPseudoElement object<br> <ydaniv> ... objections?<br> <ydaniv> RESOLVED: proposed: for a valid selector we will always return the CSSPseudoElement object<br> <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