Add an additional parameter to the argument of scrollToItem.
horizontalScrollMargin?: number | undefined;
verticalScrollMargin?: number | undefined;
When scrolling, scroll so that there is a offset of the specified numbers pixels between the target item's borders, and the scroll viewport's borders. The options have no effect if align is "center". The default value, if not specified is zero.
Ideally, margins would collapse gracefully in the horrifying border cases where there is insufficient height or width to display the cell and it's full margins (or even fully display a single cell). Landscape UI's on phones are challenging because you only have 5 or 6 notional rows of UI in the 350 pixel height of a budget phone in landscape orientation, where each row of UI interface must be at least 48 pixels high but ideally 64-pixels high. So degrading gracefully matters.
Motivation:
The current implementation scrolls so that the top, bottom, left, or right border of the target item are exactly aligned with the edge of the viewport. This gives users the incorrect impression that the item is on the last available row or column in the list being displayed. This is particularly dire on mobile/touch platforms, where scrollbars are only displayed while touch-scrolling. Even with desktop scrollbars, on has a superficial impression that the selected item is on the last row or column, creating an unpleasant sense of cognitive friction: "I know there's more, but I have to think about it for a second to be certain."
The solution is to ensure that there is a distance of a fraction of a row between the item and it's viewport borders. The fractionally displayed next row or column provide an unambiguous indication that there is more data, that can be accessed by scrolling.
While it's true that browser native APIs don't support this feature, tbh, I usually write my own implementation of scrollIntoView in most of my projects. So I would be grateful if you could do it for me. :-P The lifetime and layout timing issues are .... more challenging than usual.
I probably will write it myself, to satisfy version and release schedules. But it would be a great feature.
iahu
commented
10 months ago
Add an additional parameter to the argument of scrollToItem.
horizontalScrollMargin?: number | undefined; verticalScrollMargin?: number | undefined;
When scrolling, scroll so that there is a offset of the specified numbers pixels between the target item's borders, and the scroll viewport's borders. The options have no effect if align is "center". The default value, if not specified is zero.
Ideally, margins would collapse gracefully in the horrifying border cases where there is insufficient height or width to display the cell and it's full margins (or even fully display a single cell). Landscape UI's on phones are challenging because you only have 5 or 6 notional rows of UI in the 350 pixel height of a budget phone in landscape orientation, where each row of UI interface must be at least 48 pixels high but ideally 64-pixels high. So degrading gracefully matters.
Motivation:
The current implementation scrolls so that the top, bottom, left, or right border of the target item are exactly aligned with the edge of the viewport. This gives users the incorrect impression that the item is on the last available row or column in the list being displayed. This is particularly dire on mobile/touch platforms, where scrollbars are only displayed while touch-scrolling. Even with desktop scrollbars, on has a superficial impression that the selected item is on the last row or column, creating an unpleasant sense of cognitive friction: "I know there's more, but I have to think about it for a second to be certain."
The solution is to ensure that there is a distance of a fraction of a row between the item and it's viewport borders. The fractionally displayed next row or column provide an unambiguous indication that there is more data, that can be accessed by scrolling.
While it's true that browser native APIs don't support this feature, tbh, I usually write my own implementation of scrollIntoView in most of my projects. So I would be grateful if you could do it for me. :-P The lifetime and layout timing issues are .... more challenging than usual.
I probably will write it myself, to satisfy version and release schedules. But it would be a great feature.