How did you implement the scrolling such that it feels smooth/fast/native, but scrolls in one row/column steps (so you never see half a row)?
CSS Scroll Snap?
Nicely done.
CSS Scroll Snap?
Nicely done.
There is a blank DOM node "scrollArea" in front of all others that catches the native JS scroll event.
It then converts these scroll offsets (scrollTop and scrollLeft) to cell/viewport coordinates, by default 40px actual pixels per row/column.
So if the scrollArea has a scrollLeft of 40px and a scrollTop of 200px , an underlying DOM node that renders the cell values and column lines, will render at viewport position {x: 1, y: 5}.
The other important part that makes it snappy, is that a viewport of let's say 20 rows by 10 columns does not actually consist of 200 DOM nodes. Only columns are DOM nodes. The values inside a column are made to look like rows by CSS white-space property. So it only updates 10 DOM nodes when scrolling.
This does not happen when you paste when the editor is not open, am I correct?
The current solution that I came up with: replace \n with Return HTML-entity. Not sure if that is the best solution for you (or anybody else) but at least it prevents the unwanted shift of column contents.
Thanks again!
CSS Scroll Snapping may have a place for image gallery sorts of widgets, but for broader layout matters I strongly recommend against it: it can work tolerably on mobile (though it’s not without problems), but on desktop it seriously messes with scrolling so that on many devices it’s almost entirely problems.
Using a real scrolling area and observing what effect scrolling has upon it is the only correct way of rendering things. Then you could draw the contents in various ways—canvas (handle interactivity yourself), another DOM element behind the scrolling area (ditto), or a fancily-done `position: sticky` element that fills the visible part of the scrollable area.
Just remember that there are serious accessibility concerns about any of these sorts of things. Approach any sort of clever lazy loading of content with extreme caution.
Css native's scroll-snap was not useful in my case, but in the end DGXL's custom scroll snap was one of the easiest parts of the product to build. It was one of the things I really wanted to get right.
Using a <table> tag would always be best for accessibility reasons, but it's not an option if you want to create a performant data table with thousands of rows. I am still using HTML, not Canvas, so it is accessible, but it needs improvements.
A great relief is that this is an input-component first of all, to be used in admin-areas. So there's no need for SEO-compatible HTML.
const nextColumnIndex = scrollDeltaX < 0 ? Math.max(0, columnStart - 1) : Math.min(columnStart, columnCount - 1);
const columnWidth = getColumnWidth( nextColumnIndex );
scrollBar.scrollLeft += (scrollDeltaX < 0 ? -1 : 1) * columnWidth;
You're probably browsing the site on your phone, am I correct? I created scroll snap to replicate desktop version of Excel & G. Sheets behavior. I agree that it is not the best option for smaller viewports/touch. It's on my todo-list to introduce smooth-scrolling as well.
I initially created scroll snap to replicate desktop version of Excel & G. Sheets behavior. I agree that it is not the best option for smaller viewports/touch. It's on my todo-list to introduce smooth-scrolling as well, so that scrolling DGXL on touch will work closer to native apps.