- From: Sarah Higley via GitHub <noreply@w3.org>
- Date: Thu, 23 Jul 2026 05:16:35 +0000
- To: public-css-archive@w3.org
This would also need to exist for `event.relatedTarget`, right? I only see discussion of `event.target`/`event.pseudoTarget` in the linked issue. Without `relatedTarget`, handling blur events wouldn't be possible (e.g. when an alert dialog opens and pulls focus from the page, it's common to save the previously-focused element by looking at `relatedTarget`, and use that when returning focus after the dialog is closed). Also, just to make sure I understand -- the proposed `pseudoTarget` (and presumably `pseudoRelatedTarget`) would be present on the Event object for all event listeners up the tree, not only ones attached to the pseudoElement? I have a few other questions about the approach: - I understand the desire to not fire focus events when the user tabs or arrows between scroll markers and agree that it's better than the other options, but does that mean focus events wouldn't fire if a developer calls `pseudoElement.focus()` on different scroll markers / scroll buttons? - Can a developer attach an event listener directly to the pseudos? Would focusin/out events fire there, but not propagate? - Does the pseudo-element appear in `Event.composedPath()`? TBH, to me this seems to be introducing a fair amount of extra complexity and potential inconsistencies (e.g. suddenly the `event.target` of a _focus event_ could be unfocusable) to an area that developers already struggle with. I'm not sure I see how the benefits of focusable, semantically interactive pseudo-elements outweight the ballooning costs here and elsewhere to the overall dev experience. -- GitHub Notification of comment by smhigley Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12239#issuecomment-5054744544 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 July 2026 05:16:36 UTC