- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 01 May 2024 23:12:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-scroll-snap-2] Should pseudo-elements show up as null SnapEvent.snapTargetBlock/Inline`, and agreed to the following: * `RESOLVED: Dispatch scroll snap events on pseudo elements by targetting the ultimate originating element` <details><summary>The full IRC log of that discussion</summary> <fantasai> s/Topic/Subtopic/<br> <fantasai> i/Subtopic/Topic: Scroll Snap 2/<br> <fantasai> flackr: You can set scroll-snap-align on pseudo-elements, and UA snaps to them<br> <fantasai> flackr: what should we do for the events we're defining?<br> <fantasai> flackr: my proposal is to treat just like other targetted events, and dispatch at owning eleent<br> <fantasai> flackr: just like click etc.<br> <fantasai> flackr: Dev won't have any way to know which pseudo was targetted<br> <fantasai> flackr: could expand similar to Animations to add a string saying which pseudo<br> <fantasai> Rossen: Are there use cases for such dispatching?<br> <fantasai> flackr: Pseudo-elements can be snapped to, want to tell dev that we've snapped to something<br> <fantasai> flackr: we just don't have a way to reference the pseudo without the pseudo IDL in css-pseudo-4 which nobody has shipped<br> <fantasai> flackr: the dev will know that we snapped to something, just won't know which<br> <fantasai> flackr: could get complicated in combination with some of the ongoing current proposals<br> <fantasai> flackr: like adding snap areas to fragments etc.<br> <florian> q+<br> <fantasai> flackr: but for things like ::after/::before, probably don't need to care<br> <fantasai> florian: Seems more typical than if you snap to pseudo *and* element<br> <astearns> +1 to consistency with other targeted events (even though it isn’t entirely useful)<br> <fantasai> florian: [missed]<br> <khush> q+<br> <fantasai> florian: I would hope that we explore sooner than later how to target pseudos in general<br> <fantasai> florian: if we think the most promising approach doesn't work, then we paint ourselves into a corner this way<br> <fantasai> florian: so if we expect it to be the way forward, should make sure it is the way forward<br> <Rossen__> ack florian<br> <fantasai> flackr: I have some ideas on supporting generic events, but point taken<br> <fantasai> khush: With all the other places we've worked around lack of expressing pseudo in JS by using its originating element and string saying which pseudo<br> <fantasai> khush: noted we could give that string here<br> <fantasai> flackr: I'm proposing that just like with other events, says target is the owning eleent<br> <fantasai> flackr: if we extend later, propose matching Animations string, says targetting this pseudo with this string<br> <fantasai> khush: so right now no use case for knowing whether element or pseudo?<br> <florian> s/[missed]/and if the pseudo is the only possible target on this element, there's not much of a mistery what you snapped to. But authors are infinitely creative, so my expectation of what's typical is not necessarily warranted]<br> <fantasai> flackr: ...<br> <fantasai> Rossen: Sounds we can resolve, unless other comments?<br> <astearns> s/.../no strong use cases/<br> <fantasai> PROPOSED: dispatch events on pseudo by targetting the originating element<br> <fantasai> khush: "ultimate originating element"<br> <fantasai> RESOLVED: Dispatch scroll snap events on pseudo elements by targetting the ultimate originating element<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10175#issuecomment-2089272736 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 May 2024 23:12:31 UTC