- From: Dan Robertson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Aug 2024 22:59:23 +0000
- To: public-css-archive@w3.org
dlrobertson has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-overflow-5] clarification of scroll marker scroll position on activation when marker elements overflow == [scrolltargetelement] states: > When a [scroll marker control](https://drafts.csswg.org/css-overflow-5/#scroll-marker-control) is activated by explicit invocation or arrow key focus: > >> Let element be the [scrollTargetElement](https://drafts.csswg.org/css-overflow-5/#dom-htmllinkelement-scrolltargetelement) of the control. > > > > Let block be "start". > > > > Let inline be "start". > > > > [Scroll the element into view](https://drafts.csswg.org/cssom-view-1/#scroll-a-target-into-view) with behavior, block, and inline. > > > > If the activation was triggered by invocation > > > > [Follow the hyperlink](https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks-2) updating the URL, however retain focus on the marker element. This seems to indicate that on a user input like a arrow key press, [dom-focus] will be called on the scroll-marker element. On the other hand, it appears that [scroll tracking](https://drafts.csswg.org/css-overflow-5/#scroll-container-scroll) may not foucs the relevant scroll-marker. Could this result in large jumps in the scroll marker, since [dom-focus] from a keypress could center the scroll marker, while scroll tracking may not? [scroll tracking]: https://drafts.csswg.org/css-overflow-5/#scroll-container-scroll [scrolltargetelement]: https://drafts.csswg.org/css-overflow-5/#dom-htmllinkelement-scrolltargetelement [dom-focus]: https://html.spec.whatwg.org/multipage/interaction.html#dom-focus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10705 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 August 2024 22:59:24 UTC