Re: [csswg-drafts] [css-scroll-snap-2] Should pseudo-elements show up as null SnapEvent.snapTargetBlock/Inline (#10175)

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>
&lt;fantasai> s/Topic/Subtopic/<br>
&lt;fantasai> i/Subtopic/Topic: Scroll Snap 2/<br>
&lt;fantasai> flackr: You can set scroll-snap-align on pseudo-elements, and UA snaps to them<br>
&lt;fantasai> flackr: what should we do for the events we're defining?<br>
&lt;fantasai> flackr: my proposal is to treat just like other targetted events, and dispatch at owning eleent<br>
&lt;fantasai> flackr: just like click etc.<br>
&lt;fantasai> flackr: Dev won't have any way to know which pseudo was targetted<br>
&lt;fantasai> flackr: could expand similar to Animations to add a string saying which pseudo<br>
&lt;fantasai> Rossen: Are there use cases for such dispatching?<br>
&lt;fantasai> flackr: Pseudo-elements can be snapped to, want to tell dev that we've snapped to something<br>
&lt;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>
&lt;fantasai> flackr: the dev will know that we snapped to something, just won't know which<br>
&lt;fantasai> flackr: could get complicated in combination with some of the ongoing current proposals<br>
&lt;fantasai> flackr: like adding snap areas to fragments etc.<br>
&lt;florian> q+<br>
&lt;fantasai> flackr: but for things like ::after/::before, probably don't need to care<br>
&lt;fantasai> florian: Seems more typical than if you snap to pseudo *and* element<br>
&lt;astearns> +1 to consistency with other targeted events (even though it isn’t entirely useful)<br>
&lt;fantasai> florian: [missed]<br>
&lt;khush> q+<br>
&lt;fantasai> florian: I would hope that we explore sooner than later how to target pseudos in general<br>
&lt;fantasai> florian: if we think the most promising approach doesn't work, then we paint ourselves into a corner this way<br>
&lt;fantasai> florian: so if we expect it to be the way forward, should make sure it is the way forward<br>
&lt;Rossen__> ack florian<br>
&lt;fantasai> flackr: I have some ideas on supporting generic events, but point taken<br>
&lt;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>
&lt;fantasai> khush: noted we could give that string here<br>
&lt;fantasai> flackr: I'm proposing that just like with other events, says target is the owning eleent<br>
&lt;fantasai> flackr: if we extend later, propose matching Animations string, says targetting this pseudo with this string<br>
&lt;fantasai> khush: so right now no use case for knowing whether element or pseudo?<br>
&lt;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>
&lt;fantasai> flackr: ...<br>
&lt;fantasai> Rossen: Sounds we can resolve, unless other comments?<br>
&lt;astearns> s/.../no strong use cases/<br>
&lt;fantasai> PROPOSED: dispatch events on pseudo by targetting the originating element<br>
&lt;fantasai> khush: "ultimate originating element"<br>
&lt;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