- From: Jihye Hong via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jun 2019 18:17:22 +0000
- To: public-css-archive@w3.org
On top of this case, there are additional cases which need to reset the search origin. 1. Search origin can be disappeared (style of the element is changed to `display:none` / `visibility: hidden` / etc) In this case, the search origin would be reset to the **`Rect` of the disappeared element**. Currently, the implementation is going on which is the same approach with this: https://chromium-review.googlesource.com/c/chromium/src/+/1600930) 2. Viewport can be changed by the non-focusable element * non-focusable elements could be: * the target element of scrollIntoView API * the target element which corresponds '#id' in URL * the target fragment from searching with CTRL+F In this case, the currently focused element also moves out of the viewport. But the considerable thing is that the viewport changes because of targeting the non-focusable element. My initial opinion was resetting the search origin to the **ancestor spatial navigation container** of the currently focused element. But talking with @frivoal, we make a more precise definition of "search origin" and "spatial navigation starting point". * spatial navigation starting point: The origin for searching next target which is set by UA. This can be element or point. * search origin: The spatial navigation starting point, if it exists, but if it's not, the currently focused element. Depending on this definition, in this case, the search origin can also be reset to the non-focusable object. -- GitHub Notification of comment by jihyerish Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3391#issuecomment-499608819 using your GitHub account
Received on Thursday, 6 June 2019 18:17:23 UTC