- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 07:49:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-pseudo] Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists"``. <details><summary>The full IRC log of that discussion</summary> <ydaniv> q+<br> <kbabbitt> sakhapov: I think we should resolve for pseudo element observer<br> <TabAtkins> q+<br> <kbabbitt> ... want to hear opinions<br> <astearns> ack ntim<br> <kbabbitt> ntim: first thought looking at this api is that why don't we just make element.pseudo return null<br> <kbabbitt> ... like querySelector returns null<br> <kbabbitt> astearns: because we already resolved on having the interface ...<br> <kbabbitt> sakhapov: discussions before<br> <kbabbitt> emilio: if you do that, you need to synchronously update layout, may wantobserver for pseudeo that doesn't exust yet<br> <kbabbitt> ... otherwise if you have a before pseudo that goes away then comes back, you don't want to expose whether underlying psedo ? or not<br> <kbabbitt> ntim: exists prop checks for htat?<br> <kbabbitt> emilio: but object may not be the same<br> <kbabbitt> astearns: successive iterations of same pseudo<br> <kbabbitt> ... it's a separate issue<br> <kbabbitt> ... given previous resolution we need to decide what to do here<br> <kbabbitt> sakhapov: previous discussion was in favor of consistent proxy<br> <kbabbitt> ... good arguments for that<br> <kbabbitt> astearns: other comments?<br> <emilio> q+<br> <kbabbitt> ntim: disagree with other issue<br> <kbabbitt> ... which affects this<br> <astearns> ack ydaniv<br> <kbabbitt> ydaniv: really like the observer approach<br> <kbabbitt> ... but we're doing something specific here with pseudos<br> <ntim> where can i find the other issue?<br> <kbabbitt> ... maybe we can open something more generic<br> <kbabbitt> ... last we talked, ? talks about having selector observer when things are added/removed that match a specific selector<br> <kbabbitt> ... maybe we want a more generic thing that also works for pseudos<br> <kbabbitt> ... or mutation observer that takes selector as filter<br> <kbabbitt> ... would like to see if we could consider that<br> <kbabbitt> astearns: sakhapov has that been considered?<br> <kbabbitt> sakhapov: no, mostly considered sync way, noam is in favor of observer, see use cases for both<br> <kbabbitt> ... heard opinions in favor of observer, want to hear in favor of exists property<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: while the observer proposal from noam is a little complex to solve this, I think it's pretty well shaped<br> <kbabbitt> ... avoiding sync recalc is reasonable<br> <kbabbitt> ... agree there might be use cases for sync stuff but can pursue in future<br> <kbabbitt> ... support sticking with observer<br> <astearns> ack emilio<br> <kbabbitt> emilio: 2 things, if we do sync version , I'd rather make it a method than a getter<br> <kbabbitt> ... going to do underlying work to update layout tree etc.<br> <kbabbitt> ... also some of the use cases feel a bit dubious<br> <kbabbitt> ... don't think we want to expose whether spelling error exists<br> <ntim> spelling-error<br> <kbabbitt> ... or grammar error<br> <ntim> Is https://github.com/w3c/csswg-drafts/issues/12159 the other issue?<br> <kbabbitt> ... so not clear a lot of these have good answers for those<br> <kbabbitt> ... don't know what the right answer for those would be<br> <kbabbitt> sakhapov: ? said for privacy reasons we can't expose a number of pseudos<br> <kbabbitt> emilio: guess you want to return null when it's a tree state<br> <kbabbitt> ... true false or unexposed<br> <kbabbitt> sakhapov: there's a table in the issue<br> <kbabbitt> emilio: think that's a bad pattern, don't have a lot of nullable booleans<br> <kbabbitt> ... proposal for exists was nullable boolean<br> <kbabbitt> ... null if we can't answer<br> <kbabbitt> TabAtkins: don't think we have any nullable booleans right now<br> <kbabbitt> ...given that both null and false are false-y that fits simple test for is it there?<br> <kbabbitt> sakhapov: idea behind nullable bool was null = can't tell, false = not there<br> <kbabbitt> TabAtkins: both seem false-y to me, seems okay to me<br> <kbabbitt> emilio: feels like a lot of these ... for example first-letter, first-line<br> <kbabbitt> ... do you need a rule for them to match?<br> <kbabbitt> ... same for placeholder<br> <kbabbitt> ... could use .matches(placeholder)<br> <kbabbitt> ... highlights you know whether you have them because there's a registry<br> <kbabbitt> ... spelling error we don't want to expose<br> <kbabbitt> ... seems like theres very few where this would be useful<br> <kbabbitt> ... guess the observer, I wonder if we could reuse mutationobserver<br> <kbabbitt> astearns: that was ydaniv's suggestion<br> <kbabbitt> TabAtkins: can you filter a mutationobserver?<br> <kbabbitt> emilio: yes, only text changes, only additions, etc<br> <kbabbitt> TabAtkins: can you have default off things?<br> <kbabbitt> emilio: it's optional spec so potentially<br> <kbabbitt> ... also tricky thing with mutationobserver, we don't want to turn on details of when actual element gets createdx<br> <kbabbitt> ... seems to me like there's very few really compelling use cases for this given the complexity<br> <kbabbitt> astearns: I kind of like the idea of reusing something we already have<br> <kbabbitt> ... instead of creating something new<br> <kbabbitt> ... wonder if we should take this back to the issue, especially since noam's not here<br> <kbabbitt> ... and have him weigh ydaniv's idea against his proposal<br> <kbabbitt> sakhapov: sounds good<br> <kbabbitt> astearns: you can ping noam to say there's this other idea, and we'll weigh the alternatives<br> <kbabbitt> sakhapov: and sync version can be discussed later<br> <kbabbitt> astearns: ok, back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12158#issuecomment-3531390781 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 07:49:38 UTC