One deficiency of using the native scrollbars visually here is that the arrows at the end of the scroll bars on some platforms (e.g. Windows, most Linux) will scroll by a predetermined number of pixels, more or less, whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically. Of course, placing your own scrollbar visuals is a hazard too, most significantly because it doesn’t look native and may offer different functionality from the normal scrollbar. You can’t win, the web doesn’t give you the tools you need to get the experience perfect.

But yeah, your example in DataGridXL is a good example of the right approach to take for this if you want scrolling to be done in steps as is conventional in spreadsheets.

> whereas in such an application you would probably prefer it to scroll one column horizontally or one row (though maybe more than one) vertically.

But isn't this exactly what element.scrollIntoView() is supposed to be for?

Native scrollbars, styled with scrollbar-width and textareas resizing with cols attribute is pretty straight forward if you do the box-sizing right.

I think you’re misunderstanding. I’m saying that on platforms where the native scrollbar has arrows that you can click to scroll by a small amount in the nominated direction, you might prefer clicking on those arrows to do something different—to scroll one row or one column, whatever distance may be, rather than however many pixels the user agent decides. But you can’t do that on the web.

element.scrollIntoView() is completely unrelated to this.

Ah gotcha, yes you are indeed correct. Something like custom amount of lines to scroll isn't possible afaik.

I was just stating that with scrollIntoView and the element's scroll-snap-align and scroll-padding/scroll-margin CSS properties you could set the wanted offsets and alignments of the scrollbar and define what you were argueing about.

But of course, you cannot influence the behaviour of the scrollbar arrows themselves.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-snap...

Ah, CSS scroll snapping. Refer to my other comment in this thread about that, I strongly recommend against using it for layout matters like this, it messes with the scrolling behaviour (especially on devices with precise-scrolling touchpads and inertia) something fierce; it’s quite unavoidably every bit as bad as doing the scrolljacking in JS.

You know your stuff, I can tell! In a pre-release version, we had hidden the native scrollbar and put our own scrollbar graphic on it that would animate using CSS transform according to native scroll offsets vs. DGXL viewport dimensions. The scrollbar size (width/height) and position made more sense, but at the end we couldn't get it to feel quite right.

We're quite happy with the native scrollbar. It's fine on mobile too.

Yep, I think native scrollbars is reasonable for DGXL. Maybe eventually you’ll sniff whether scrollbars take space and draw your own that match the size if they do, but it’s definitely a little risky.

These sorts of things are particularly interesting once you support a sparse spreadsheet; drawing your own scrollbars becomes much more compelling then, so that you can make them more useful. No idea about Excel, but LibreOffice Calc—(which amusingly gets scrolling by precise touchpad wrong in just the same way as Luckysheet, sans the wrong horizontal direction; this stuff is hard everywhere)—well, LibreOffice Calc’s scrollbars essentially pretend the whole time that the document is only as large as the extent of the cells with content or the selection, whichever is larger in each axis, plus a screenful or so in each axis. So if you’re at A1 of an empty document, the scrollbars thumbs fill about half of the bar, but if you’re at AMJ1048576 (maximum sheet dimensions are 2¹⁰×2²⁰), the thumbs are tiny at the bottom and right.

Sounds like a very strange approach, those LibreOffice Calc scrollbars ;-) Sometimes it's useful to give a minimal width/height for a scrollbar thumb, so that it remains visible and selectable. A tiny scrollbar thumb might be "realistic" when it represent the viewport vs document dimension, but it always looks a bit stupid.

How come you know so much about scroll bars? Did you make your own spreadsheet app/component?

The spreadsheet approach makes a lot of sense: they’re dealing with what’s practically a near-infinite document (a million cells is close enough to infinity in such cases!), but people seldom actually use that many cells. Thus, the shenanigans they pull are to make the scrollbars useful, so that they typically give a fair reflection of the actual size of the document the user is dealing with. I imagine Excel does something similar.

I know so much mostly just because I observe carefully, in both desktop and web software. I haven’t implemented anything like this, but when I observe things imperfect on the web and it’s a type of imperfection I’m not familiar with, I often assess it to figure out whether it’s possible to get right. I also value getting things right in straight HTML/CSS with no JavaScript.

Your implementation is pretty neat.

We recently kind of went down the path of our own scroll bar in one of our app forms because users wanted the scroll to behave in a very specific way. It was impossible to make it work as expected in all the OS and browsers. We eventually rolled back the change, restored the native scroll bar and instead provided a big optional floating scroll button in the bottom corner of the app which user can choose to use to scroll the way they expected to. Kept everyone happy.

Thanks, we really wanted to get the scrolling right so I'm glad it shows.

> We eventually rolled back the change, restored the native scroll bar

Doesn't it feel good to remove a bunch of "hacky code" and just go back to native? Even if it's not 100% like you imagined, at least you know that the other "perfect solution" never really existed.