Re: [csswg-drafts] Should non-tree-abiding pseudo elements have a separate IDL interface? (#12160)

The CSS Working Group just discussed `Should non-tree-abiding pseudo elements have a separate IDL interface?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;flackr> q+<br>
&lt;TabAtkins> sakhapov: This issue is just about what we return for non-tree abiding pseudos.<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> sakhapov: they might need a different type, not inherited from eventtarget, because they don't actually fit into the bubbling model<br>
&lt;TabAtkins> flackr: in the issue i said highlightsFromPoint isn't a great API, we watned an event listener on the highlight pseudo<br>
&lt;TabAtkins> flackr: so i'd prefer, as much as possible, to have the same interface<br>
&lt;TabAtkins> flackr: only thing I'd say is that if we start exposing the tree structure of tree-abiding pseudos, we'd say that non-tree abiding don't have children<br>
&lt;TabAtkins> flackr: but for event listeners, i think it still makes sense<br>
&lt;TabAtkins> sakhapov: I wrote that these can't always be in the bubbling model, but can you elaborate on your case?<br>
&lt;TabAtkins> flackr: the highlightsFromPoint api handles clicks on a highlight. but the way to do that right now is to add a click event listener on an ancestor and then querying which highlights were clicked.<br>
&lt;TabAtkins> flackr: a bette rmodel is to add an event listener to the highlight pseudo. we'd have to figure out the event dispatch, but we could figure it out<br>
&lt;TabAtkins> flackr: so devs would just be direclty notified that you've clicked on a highlight pseudo<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: interesting q here, which we get to on other issues, is what is the identity of the highlight pseudo? is it the one the author needs it to be?<br>
&lt;TabAtkins> fantasai: there's kinda three different concepts, maybe four<br>
&lt;TabAtkins> fantasai: example, suppose i want to represent spelling errors. three differnet misspelled words. one in the first, one in the second, third is partly bolded.<br>
&lt;TabAtkins> fantasai: when i select ::spelling-error, i'm selecting all of these<br>
&lt;TabAtkins> fantasai: but i get all of them becuase i wrote p::spelling-error, on two different p, and a b::spelling-error that is the bolded part of the third word<br>
&lt;TabAtkins> fantasai: from the author's persepctive there are three misspelled words, but there are more than three pieces here<br>
&lt;TabAtkins> fantasai: from our perspective, the bolded and non-bolded are two different pseudos<br>
&lt;TabAtkins> fantasai: so the author might be interested in different things. the entire set, each individual range, or the pieces associated with a single element<br>
&lt;TabAtkins> fantasai: we're interested in the pieces associated with an element, becuas eit's what we style<br>
&lt;flackr> qq+<br>
&lt;TabAtkins> fantasai: from a css perspective, the two halves of the semi-bolded word are two different pseudos, two different boxes, styled separately<br>
&lt;TabAtkins> fantasai: but the author isn't thinking about that, they're probably seeing three spelling errors<br>
&lt;TabAtkins> fantasai: i don't know we ahve the model that gets authors what they want to identify<br>
&lt;TabAtkins> fantasai: we'll have to build up that model before we can attach event listeners to it<br>
&lt;astearns> ack flackr<br>
&lt;Zakim> flackr, you wanted to react to fantasai<br>
&lt;TabAtkins> flackr: i haven't thought about addEventListener side yet, but on dispatch side, the event target woudl be the specific element that you clicked on, witht he pseudoElement property pointed at the pseudo you actually clicked on<br>
&lt;TabAtkins> flackr: I don't want to derail things. some things will never make sense on tree-abiding pseudos ever, but aspirationally we'll want to support event listening. better than a polling model, which is what's needed today<br>
&lt;TabAtkins> fantasai: yeah wont' dispute that, it'll just be complicated to figure out<br>
&lt;TabAtkins> flackr: yeah, so maybe have even tlisteners on non-tree-abiding on hold until we figure it out. maybe that'll eventually mean separate interfaces.<br>
&lt;TabAtkins> astearns: even if we never have a way to add events, even if we have the same interface we could have the APIs return null or error?<br>
&lt;TabAtkins> flackr: you'd just notice you never get an event from it. but we could also error, yeah.<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: do we have an OM interface representing highlight pseudos yet?<br>
&lt;TabAtkins> fantasai: because it's not just event handling that they want it for. anything you want to do with it, these questions come up<br>
&lt;TabAtkins> astearns: lets' take this 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/12160#issuecomment-3005284668 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:50:35 UTC