- From: Dan Robertson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 21 Nov 2022 20:57:00 +0000
- To: public-css-archive@w3.org
Thanks! This does solve the issue of adding the handler, but I wonder if we need something in the actual firing section. E.g. `scroll` has: > If target is a [Document](https://dom.spec.whatwg.org/#document), [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) named [scroll](https://drafts.csswg.org/cssom-view/#eventdef-document-scroll) that bubbles at target and fire an event named scroll at the [VisualViewport](https://drafts.csswg.org/cssom-view/#visualviewport) that is associated with target. For `scrollend`, we only have: > If scrolling was done on a [viewport](https://drafts.csswg.org/css2/#viewport%E2%91%A0), let doc be the viewport’s associated [Document](https://dom.spec.whatwg.org/#document) and target be the viewport. Otherwise, scrolling is done on an element and let doc be the element’s [node document](https://dom.spec.whatwg.org/#concept-node-document) and target be the element. I think we need to specify that in some cases we need to fire a scrollend event for the `VisualViewport`. The wording of the `onscroll` steps still confuse me a bit. I'm still not sure how they specify that in some cases we should only fire `Document.scroll` and in some cases only `VisualViewport.scroll`. I'm okay with splitting off this addition of some documenting text for firing the scrollend event into another bug though. -- GitHub Notification of comment by dlrobertson Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8103#issuecomment-1322630672 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 21 November 2022 20:57:02 UTC