Comments (7)
hugoholgersson
commented on June 15, 2024
Taking scroll-padding into account adds more complexity to the algorithm, doesn't it?
from spatial-navigation.
frivoal
commented on June 15, 2024
I guess so, but not by much, this is just using one rectangle instead of another rectangle.
For now, scroll-padding is new, so people have relatively few expectations linked to it, and we have relatively little experience about how it is typically used. A major anticipated use to to declare "off limits" the sides of a scroller that are overlapped (possibly partially) by something. In which case, scroll-padding is acting as a proxy for (some cases of) hit testing.
If we have actual hit testing (which the spec currently calls for), then it may not be useful to account for scroll-padding as well.
However:
- Maybe hit testing isn't actually practical. We're not asking for "can this point be hit", but "can any point be hit". I do not know how performantly this can be implemented. If it turns out we cannot have it, the
scroll-paddingcan take care of a range of cases where visibility on the sides is impeded. - Maybe people will use
scroll-paddingfor reasons other than visibility, to give things breathing room. In that case, it sounds like taking it into account would be nice as well.
However, it is meant to
I am thinking that:
- if it turns out we cannot use hit-testing to include / exclude elements (maybe it's too expensive), then taking
scroll-paddinginto account gives an OK approximation for some situations
from spatial-navigation.
anawhj
commented on June 15, 2024
It seems that scroll-padding would be working only if snapping is on. I think we can access an element using SpatNav, even if the element is on the scroll-padding area.
BTW, both SpatNav and snapping are enabled in a web page, which one gets a higher priority? I found that one of default behavior of arrow keys would be snapping (scrolling as a unit of specified offset), so we should care this situation. I think, in this case, snapping has a higher priority than SpatNav.
Back to this issue, visible candidates might be able to be found in the scrollport.
from spatial-navigation.
hugoholgersson
commented on June 15, 2024
If one arrow-key scroll step, no matter how big/small that step is, reveals focusables - then those focusables should be considered reachable = "navigable" = candidates, right?
(The fact that arrow-key scrolling will stop at or continue until a scroll snap point shouldn't matter?).
from spatial-navigation.
anawhj
commented on June 15, 2024
When you use the scroll snap feature, the one arrow-key scroll step doesn't change the focus. For that reason, I think it would be one of the arrow keys' default behavior, unlike just a change of the scroll offset by arrow keys. You can see the behavior where the focus is always in a document(<body>), though when snapping(=changing scroll offset as a snap unit) in the following example. (preferably run it on FF)
https://hospodarets.com/demos/scroll-snap-full-screen
On second thought, we could manage the focus using SpatNav in a single snap unit. If the focus is about to go outside of scrollport, the snap operation is executed at the moment, but it would have to be more investigated later. (probably level 2)
FYI, Snap Points design document (Chromium)
https://docs.google.com/document/d/1xbc9W_Ac-ve0gE_ppT9y8aydVJJ7NXUL-9MVq0yPhsE
from spatial-navigation.
frivoal
commented on June 15, 2024
scroll-padding works even when snapping is not turned on. The goal of srcoll-padding is for the author to show that there is an area at the edge of the scroller that is not good to place elements in when you try to interact with them or read them.
For example, if there is an absolutely positioned / sticky positioned banner that hides the first 50px of the scroll port, then the author should set scroll-padding-top to 50px. That way, if someone focuses something that would be hidden by that banner (using script or the tab key), or if someone navigates to the #anchor of an element that would be hidden by the banner, then the browser will scroll to move it past the 50px, and make it visible.
So, with spatnav, if the element becomes focused, it will cause the scroller to scroll, in order to move it past the 50px as well. The question is: instead of focusing it while it was hidden, and scroll to make it not hidden, should the "move up" request by the user have scrolled (without focusing) instead when it was hidden, and the next "move up" would then have focused it, because it is now visible?
When it is outside of the scrollport, that's what happens. I think it should probably be what happens when it is inside the scrollport but outside the optimal viewing region.
If one arrow-key scroll step, no matter how big/small that step is, reveals focusables - then those focusables should be considered reachable = "navigable" = candidates, right?
Yes, but the question is what do we mean by "reveals". Should we do it strictly on visibility? scroll-padding is meant to allow the author to say: "even if this is in the scrollport, this area is a bad place". That seems worth listening to.
If it turns out that the "Remove from visibles items are obscured by other parts of the page" step cannot be efficiently implemented (and I think there's a real risk that that's the case, and will discuss with the csswg at the next F2F), I think it is pretty important to respect scroll-padding. If it can, then I am less sure.
from spatial-navigation.
frivoal
commented on June 15, 2024
Putting this on the CSSWG's F2F agenda. The key question for the CSSWG and browser implementors is:
Hit testing, where you check which a element/box would be hit if you click at a certain position, or whether a particular element would be hit by clicking at a position is an existing part of the web platform. However, is the following related-but-different check is practical to implement:
can a particular element/box be hit (in the sense of hit-testing) at any point, or is it entirely obscured by other elements?
The context for wanting this check is that we would like to exclude from spatial navigation elements that are hidden behind other things (like pop-over, dialogs, etc), because it is quite likely both of the following statements are true:
- It is not rare for authors to forget about disabling (e.g. by setting the
inertattribute) elements that are obscured by temporary dialogs - It is not rare for authors to implicitly assume that elements which cannot be clicked on (because they are obscured) will not be activated, and application logic may break if this assumption is violated.
Stated differently, we would like to make the same elements reachable by spatnav as those that are reachable by clicking (and only those), without requiring the author to do anything in particular.
If this is not possible, it seems that relying on the optimal viewing region (i.e. taking the scroll-padding property into account) will give us an approximation for the full solution in some of the the cases, and that authors will need to manually disable things in other cases.
from spatial-navigation.
Related Issues (20)
- More precise `isVisibleStyleProperty` function
- Using Spatial Navigation Action API
- How to handle Popup focus navigation HOT 1
- Spatial Navigation Containers HOT 2
- navigateChain in polyfill does not seem to always use supplied focusable option parameter
- Arrow keys always move scrollbar HOT 1
- focus suddenly moves out of the scroll container
- Focus looping when the focused elements are overlapped with their borders
- Sometimes focus cannot move out of the iframe for left/right navigation direction
- Remove 'inside' option from spatialNavigationSearch
- Can this be used with canvas/webgl/pixi.js? HOT 5
- Browser Support seems to be wrong HOT 5
- Consideration of keyup event for Polyfill instead of keydown HOT 1
- spatial navigation polyfill does not move the focus to the adjacent element: HOT 1
- shadow dom (open) support HOT 8
- spatial navigation polyfill does not check the state of unrelated modifier keys like Ctrl/Meta/Alt... HOT 2
- How would screen reader users use spatial navigation? HOT 3
- Can not access the demo page HOT 1
- container.getSpatialNavigationContainer is not a function HOT 2
- Performance Issues - Layout Thrashing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spatial-navigation.