Re: [csswg-drafts] [css-om-view] How does scrolling relate to mouseWheel event propagation? (#4680)

The CSS Working Group just discussed `Mousewheel Event Propagation`, and agreed to the following:

* `RESOLVED: Over the border area, doesn't scroll the content area`
* `RESOLVED: So proposed resolution is that scroll behavior propagates through the containing block chain`
* `RESOLVED: Add these rules to cssom-view, add smfr as editor`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: Mousewheel Event Propagation<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4680<br>
&lt;fantasai> smfr: Running into some issues with how nesting scrolling works, and differences between browsers<br>
&lt;fantasai> [display fragments into weird pieces]<br>
&lt;fantasai> smfr: I look example showing when the events are received<br>
&lt;tantek_> me more Mondrian than Picasso TBH<br>
&lt;bkardell_> https://codepen.io/smfr/pen/RwNvVPj<br>
&lt;bkardell_> ^^^<br>
&lt;smfr> https://codepen.io/smfr/full/rQZqxo<br>
&lt;fantasai> smfr: First question is, if your pointer is over the border of the element<br>
&lt;fantasai> smfr: and you initiate scrolling<br>
&lt;fantasai> smfr: do you scroll that element's overflow region?<br>
&lt;fantasai> smfr: in WebKit, yes<br>
&lt;fantasai> smfr: in Firefox, answer is yes<br>
&lt;fantasai> smfr: in Chrome, answer is no<br>
&lt;fantasai> smfr: My pointer over the border of the element, I scroll the main page in Chrome<br>
&lt;fantasai> smfr: Difference #1<br>
&lt;fantasai> smfr: Other interesting thing about Chrome, notice the element is still receiving wheel events<br>
&lt;fantasai> smfr: even though I'm not scrolling it<br>
&lt;fantasai> smfr: so disconnect between when an element receives scroll events and when it actually gets scrolled<br>
&lt;fantasai> smfr: ...<br>
&lt;bkardell_> what about :hover - does it work on the border?<br>
&lt;fantasai> smfr: Things also get interesting when you start nesting scrollers<br>
&lt;fantasai> bkardell_, yes<br>
&lt;fantasai> smfr: Now, same thing, parent scroller here<br>
&lt;fantasai> smfr: it has two descendant elements, but those elements are absolutely-positioned, and the scroller is not their containing block<br>
&lt;TabAtkins> s/.../I think it's reasonable that browsers may have assumed that users only want to scroll when the mouse is actually in the content/<br>
&lt;fantasai> smfr: when I scroll the left abspos, it's a DOM descendant of the big scroller, and the big scroller receives wheel events becaue of DOM propoagation<br>
&lt;fantasai> smfr: but when I reach the end of the little scroller, the big scroller does not scroll<br>
&lt;fantasai> smfr: in WebKit and Firefox<br>
&lt;fantasai> s/Firefox/Chrome<br>
&lt;astearns> q?<br>
&lt;fantasai> smfr: but in Firefox, the big scroller scrolls after I reach the end of the little scroller<br>
&lt;fantasai> dbaron: That seems wrong to me<br>
&lt;fantasai> dbaron: I would expect it to scroll the ancestor only if  ...<br>
&lt;fantasai> dbaron: Seems that scroll propagation should follow containing block containment<br>
&lt;fantasai> s/dbaron/smfr/<br>
&lt;fantasai> dbaron: I'm not sure<br>
&lt;fantasai> dbaron: If you have somehting with overflow: scroll<br>
&lt;fantasai> dbaron: I'll invent the term "containing block child", to descrie it more as a tree for this discussion<br>
&lt;fantasai> dbaron: An element with overflow:scroll might have containing block children that move when it scrolls, and containing block children that don't move when it scrolls?<br>
&lt;fantasai> dbaron: or do they all move when it scrolls?<br>
&lt;fantasai> smfr: I think they all move when it scrolls<br>
&lt;heycam> fantasai: I think that's true since I don't know how you'd fix the element to any scroll port other than that element's<br>
&lt;fantasai> s/element/viewport/<br>
&lt;fantasai> dbaron: Concerned about sticky<br>
&lt;fantasai> dbaron: or abspos<br>
&lt;fantasai> dbaron: maybe containing-block-ness is right<br>
&lt;fantasai> dbaron: I would expect scrolling to propogate the scrolling up to the next thing that would cause the thing where your mouse is to move<br>
&lt;fantasai> smfr: I think that makes sense<br>
&lt;fantasai> dbaron: This might be something Mats has an opinion aout<br>
&lt;fantasai> s/aout/about/<br>
&lt;fantasai> emilio: Following regular box order is more similar to what the events do<br>
&lt;fantasai> smfr: Prolem with that is that it's easy to construct content where you might mask scroll ... end up scrolling something unrelated on the page just because it happens to be in the DOM parentage<br>
&lt;fantasai> dbaron: with DOM events you also have the ability to look at what the event target it<br>
&lt;fantasai> s/it/is/<br>
&lt;fantasai> fantasai: Do we want to resolve the question about borders first? Seems simper.<br>
&lt;fantasai> smfr: Which do people prefer?<br>
&lt;fantasai> dbaron: I was surprised when you showed me what Firefox does<br>
&lt;fantasai> heycam: the border should move if I'm hovering over it and try to scroll<br>
&lt;fantasai> iank_: I think that's why we have this behavior<br>
&lt;fantasai> AmeliaBR: From the DOM perspective, seems reasonable that event going to element should cause it to scroll<br>
&lt;fantasai> AmeliaBR: maybe from user perpective preferred behavior is different<br>
&lt;fantasai> AmeliaBR: but if doing it that way, maybe give script some affordances to figure out what's happening<br>
&lt;fantasai> AmeliaBR: because right now would have to evaluate the coords against layout and stuff<br>
&lt;fantasai> AmeliaBR: I think it's weird to have the default behavior that we cannot recreate with script, if you want to do something else in response to wheel events<br>
&lt;fantasai> iank_: Subtracting borders from the rectangle, lots of libraries for these types of calculations<br>
&lt;heycam> fantasai: I don't think it's that weird from a user perspective for it to scroll<br>
&lt;heycam> ... for a similar reason, if hovering over the scrollbar, it scrolled<br>
&lt;heycam> ... the scrollbar doesn't move<br>
&lt;heycam> fantasai: the thumb does but the scrollbar itself doesn't<br>
&lt;heycam> ... I'm not convinced frmo a user perspective it's that terrible for the element's contents to scroll when hovered over the border<br>
&lt;heycam> smfr: if you were interacting through touch rather than pointer would you have the same opinion<br>
&lt;heycam> ... with touch users have an expectation that the thing under the finger moves<br>
&lt;heycam> ... I think it's less obvious then that you want to scroll the content rather than everything else<br>
&lt;heycam> fantasai: it's less obvious, but unless the border was absolutely huge, I probably wouldn't be surprised or notice<br>
&lt;fantasai> astearns: Not hearing much consensus<br>
&lt;heycam> smfr: I would prefer that you only scroll when you're in the scrollable part of the content<br>
&lt;fantasai> smfr: I would prefer you only scroll over the scrollable part of the conent, withint he padding box<br>
&lt;fantasai> astearns: I think it's a little weird to scroll when your cursor is over the right border, which is outside the scrollbar itself, but top / left / bottom seems fine to me. So I'm mixed.<br>
&lt;fantasai> iank_: From our perpective, I don't have full back story, but I'm guessing that someone did this for a good reason at some point<br>
&lt;fantasai> smfr: I think you inherited it from WebKit<br>
&lt;fantasai> iank_: We've changed a lot of stuff in this area<br>
&lt;fantasai> astearns: thought webkit does scroll over the border area and Blink does not<br>
&lt;fantasai> iank_: Right, I expect somebody intentionally made the change<br>
&lt;fantasai> smfr: Not sure we need to resolve now, but one thing I would like maybe to resolve on is that there isn't a simple relationship between an element receiving a wheel event and scrolling happening in that element<br>
&lt;fantasai> smfr: both because of the border issue and also the containing block issue<br>
&lt;fantasai> astearns: We could resolve on that, but then without the pariculars, not sure what use that resolution is<br>
&lt;fantasai> smfr: maybe that's not something to resolve on, but something to use as basis for future discussions<br>
&lt;fantasai> iank_: Sounded like smfr you preferred our behavior?<br>
&lt;fantasai> iank_: Sounded like dbaron and heycam, you also did?<br>
&lt;fantasai> heycam: I think so. I don't feel super strongly about it<br>
&lt;fantasai> astearns: OK, then let's try to resolve that when the cursor is over the border area, mousewheel events will not scroll the content area. Anyone object?<br>
&lt;fantasai> fantasai: I don't feel strongly about it<br>
&lt;fantasai> RESOLVED: Over the border area, doesn't scroll the content area<br>
&lt;fantasai> astearns: second part<br>
&lt;fantasai> astearns: has the border case and also the content area case<br>
&lt;fantasai> iank_: ...<br>
&lt;fantasai> smfr: I've seen some odd behaviors where sometimes scrolling over the border of an abspos child causes its parent that's not in the containing block chain to scroll....<br>
&lt;fantasai> bkardell_: Should any child, if you're on the border, you're technically inside<br>
&lt;fantasai> bkardell_: you're on the border, does it scroll the parent?<br>
&lt;fantasai> iank_: I can try and rationalize what potentially happens<br>
&lt;fantasai> iank_: wheel events get delivered even when the element isn't scrolling, to the element directly under the pointer, and they bubble up<br>
&lt;fantasai> iank_: you can create applications which don't necessarily scroll, but they do intercept wheel events<br>
&lt;fantasai> iank_: following that logic, makes sense to still deliver wheel events on the border box<br>
&lt;fantasai> smfr: I think so<br>
&lt;fantasai> smfr: Nothing I've said is about propoagating wheel events. The should follow normal DOM propagation and hit-testing rules<br>
&lt;fantasai> iank_: So your concern is mainly around abspos<br>
&lt;fantasai> smfr: My concern was that when use rinteraction with mouse wheel events triggers scrolling, disassociated with DOM wheel events, and different between browsers<br>
&lt;fantasai> smfr: would like it to be more specified<br>
&lt;fantasai> smfr: User interface aspect of when /how scrolls propagate, somewhat ndependent of event propagation<br>
&lt;fantasai> iank_: so concern is hwere the actual scroll propoagates to an dwhen<br>
&lt;fantasai> smfr:  I think there's nothing to change about how wheel events change, nothing to do there.<br>
&lt;fantasai> astearns: so proposed resolution would be that actual scrolling behavior only propagates through the DOM tree if the pointer is over the content area of the scroller, is that correct?<br>
&lt;fantasai> smfr: I think it has to be described in terms of conaining block<br>
&lt;fantasai> smfr: assuming dbaron consideres gecko behavior a bug, with ... once you reach the end of the ...<br>
&lt;AmeliaBR> astearns version makes the most sense to me. The event propagates, but the scroll container checks the mouse position before actually scrolling or propagating further.<br>
&lt;fantasai> smfr: ONe thing that does not happen, you don't do a deep hit test, and find some ancestor becuase it happens to be under the mouse cursor, but covered by something else<br>
&lt;fantasai> smfr: you find the most descendant scroller, then ancestors scroll depending on whether in the ancestor containing block chain<br>
&lt;fantasai> smfr: For example, my testcase has the righthand element, which is not scrollable<br>
&lt;AmeliaBR> But what happens if the element that gets the event *isn't* a decendent of the scroller that is behind it…<br>
&lt;fantasai> smfr: if my mouse is over this half of it, scrolling will scroll he page.<br>
&lt;fantasai> ...<br>
&lt;fantasai> smfr: webkit has bugs because some parts uses conaining block chain, and some parts uses DOM ancestry, and when they don't match you get bugs<br>
&lt;fantasai> astearns: summarize proposed resolution?<br>
&lt;fantasai> smfr: Scroll propagation between nested overflow: scroll propagates through containing block chain<br>
&lt;fantasai> iank_: potential nasties<br>
&lt;fantasai> iank_: scrolling the left box, and cursor for brief amount of time is over the big scroller<br>
&lt;fantasai> iank_: and we currently don't scroll that, if that makes sense<br>
&lt;fantasai> smfr: Talking about latching, decide which element is scrolling at the beginning<br>
&lt;fantasai> smfr: not scrolling other things even though mouse has moved<br>
&lt;fantasai> smfr: next gesture, choose the thing to scroll again<br>
&lt;fantasai> https://www.w3.org/TR/css-display-3/#containing-block-chain<br>
&lt;fantasai> iank_: right<br>
&lt;fantasai> smfr: So that's another thing that's completely unspecified, and maybe there should be some words in the spec about it<br>
&lt;fantasai> astearns: So proposed resolution is that scroll behavior propagates through the containing block chain<br>
&lt;fantasai> iank_: I think that's fine, I think that's what our current impl does<br>
&lt;fantasai> astearns: Concerns from other implementers?<br>
&lt;fantasai> astearns: Alright, now objections? Anyone want to object?<br>
&lt;fantasai> RESOLVED: So proposed resolution is that scroll behavior propagates through the containing block chain<br>
&lt;fantasai> ACTION smfr File open issue against latching behavior<br>
&lt;fantasai> smfr: Does this go into cssom-view or what?<br>
&lt;fantasai> heycam: Seems like most relevant spec<br>
&lt;heycam> fantasai: overflow doesn't do anything with events.  cssom view has some scrolling stuff, some scroll apis<br>
&lt;heycam> ... don't know what extent it really fits in with either, but would go with CSSOM since it's talking about DOM stuff<br>
&lt;fantasai> i/fantasai/emilio: maybe css-overflow?<br>
&lt;fantasai> astearns: OK, we'll put in cssom-view. Which doesn't have an editor.<br>
&lt;fantasai> astearns: smfr can I add you as editor?<br>
&lt;fantasai> RESOLVED: Add these rules to cssom-view, add smfr as editor<br>
&lt;fantasai> heycam: Another question, which element's pointer values do we look at to decide if it's going to scroll or not?<br>
&lt;fantasai> heycam: especially wrt looking at ancestors to see what to scroll<br>
&lt;fantasai> s/pointer/pointer-events/<br>
&lt;fantasai> smfr: I think we evaluate pointer-events when we do the hit testing, so only when finding the element to scroll<br>
&lt;fantasai> smfr: unsure about abspos and stuff<br>
&lt;fantasai> astearns: Good question, maybe open an issue?<br>
&lt;fantasai> heycam nods<br>
&lt;fantasai> astearns: Anything more on scrolling today?<br>
&lt;fantasai> smfr: That's all I have<br>
&lt;fantasai> astearns: Thanks for calling in<br>
&lt;fantasai> astearns: Let's go through Motion issues, because we have Amelia on the line<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4680#issuecomment-577778854 using your GitHub account

Received on Thursday, 23 January 2020 17:12:54 UTC