Re: [csswg-drafts] Add a property to the `CSSPseudoElement` IDL interface to determine if a pseudo element "exists" (#12158)

The CSS Working Group just discussed ``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>
&lt;sakhapov> sakhapov<br>
&lt;ydaniv> sakhapov: want to discuss pseudo-element interface to use it from JS<br>
&lt;ydaniv> ... element.pseudo, if object is valid the the pseudo is used<br>
&lt;ydaniv> ... has several props like using identity for event delegation<br>
&lt;ydaniv> ... ability to distinguish if element is rendered or exists<br>
&lt;ydaniv> ... add property exists per element<br>
&lt;oriol> q+<br>
&lt;ydaniv> ... si add property per element defined and supported<br>
&lt;ydaniv> oriol: not sure if this make sense for some elements<br>
&lt;ydaniv> ... whether this interface would be able to work for any element, or just tree-abiding ones<br>
&lt;ydaniv> ... not sure whether it's well defined<br>
&lt;ydaniv> ... also whether if there's a generated box for this element<br>
&lt;ydaniv> ... you only want to check whether it exists or not<br>
&lt;ydaniv> ... also has perf concerns, to check if has generated boxes<br>
&lt;ydaniv> ... so makes sense to add extra APIs for these<br>
&lt;flackr> q+<br>
&lt;ydaniv> sakhapov: for now defined only for 4-5 elements<br>
&lt;astearns> ack oriol<br>
&lt;ydaniv> ... we can later defined for other elements, and having same interface for element and pseudo<br>
&lt;ydaniv> ... each opseudo is unique and different, so makes sense to define per element, and later generalize<br>
&lt;ydaniv> oriol: so makes sense to define per element if box exists or something different<br>
&lt;ydaniv> sakhapov: yes, for example for :column<br>
&lt;ydaniv> flackr: I think Daniil covered all my points, part of goal here to define the exists and can be different, like whether selection exists<br>
&lt;astearns> ack flackr<br>
&lt;ydaniv> ... part of it is defined whether exists, because if has box is different<br>
&lt;schenney> q+<br>
&lt;ydaniv> sakhapov: gCS for highlight pseudos it returns styles as if active, so not same as box is present<br>
&lt;astearns> ack dbaron<br>
&lt;ydaniv> dbaron: I think this seems reasonable, agree we define existance per element<br>
&lt;ydaniv> ... for customisable select we defined sepcific mechanism, my intuition is that it should return true only if has select on element, .... &lt;missed><br>
&lt;TabAtkins> Big +1 to dbaron (and I think I feel a bit more strongly about it)<br>
&lt;dbaron> questions: 1. whether ::checkmark existing depends on whether the &lt;select> has appearance:base-select<br>
&lt;dbaron> 2. whether ::checkmark existing depends on whether the popup is open<br>
&lt;astearns> ack schenney<br>
&lt;dbaron> 3. (from alan?) whether ::checkmark existing depends on whether the option is currently checked<br>
&lt;dbaron> (I think yes to 1 but not to 2 and 3, but we probably need to define the underlying principles.)<br>
&lt;ydaniv> schenney: for many pseudos it should return whether active or not has also privacy concerns, so we return regardless same style<br>
&lt;fantasai> Definitely no dependency on #3 -- ::checkmark is intended to be available for styling iconography in the unchecked state as well.<br>
&lt;ydaniv> ... also currently defined 4 pseudos availabe, and we can define for each case<br>
&lt;ydaniv> ... we can punt on the rest later<br>
&lt;astearns> q+<br>
&lt;ydaniv> astearns: a little concerned about having this single member mean different things for different pseudos and whether has a single true on false for different cases<br>
&lt;ydaniv> ... sometimes you want to tell whether there's a box, so I think we should take this back to the issue<br>
&lt;flackr> qq+<br>
&lt;ydaniv> ... define what this might mean per element or whether we can define something genetal<br>
&lt;astearns> ack flackr<br>
&lt;Zakim> flackr, you wanted to react to schenney<br>
&lt;ydaniv> s/genetal/general/<br>
&lt;astearns> ack astearns<br>
&lt;ydaniv> flackr: should define whether something is defined for this check and whether needs better definition, we should be talking about actual use-cases<br>
&lt;kbabbitt> +1 to flackr<br>
&lt;fantasai> +1 flackr<br>
&lt;schenney> +1<br>
&lt;ydaniv> astearns: any comments<br>
&lt;ydaniv> ... taking it back to the issue and define per element and get a clear picture first<br>
&lt;ydaniv> sakhapov: sounds good<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-3005179129 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:19:45 UTC