Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Luckysheet, an open-source spreadsheet

github.com

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Luckysheet, an open-source spreadsheet

#101

Post by chrismorgan »

microcolonel wrote: post #83
cosmodisk wrote: post #59

Earlier quoted context omitted.

Do you happen to have some links to resources I could read a bit more about it?

There are some intricacies about when to reset the scroll position, if ever. Here's one way: https://codepen.io/xorgy/pen/yYdVoY

This way is very, very wrong in how it resets the scroll position: it essentially assumes synchronous scrolling, and falls apart completely if that isn’t the case—and it hasn’t been for some years.

By “synchronous scrolling” I mean that reading scrollTop gets you the true current value, and that setting scrollTop sets the value immediately. These used to be the case, but scrolling is handled off-thread now, so the values you read may not be the actual values, and your setting the value may clobber scrolling that has taken place since your code started being called. (This also means that any fake scrolling you do will lag behind reality—one of the reasons to use fully native scrolling if you possibly can. This has been unavoidable since asynchronous scrolling came in.)

The effect is that on devices with precise scrolling and inertia especially, it will make scrolling extremely slow, because essentially most of the scrolling delta is being lost. I see this problem very commonly in systems that have tried to implement their own scrolling. For reference, I’m using Firefox on a Surface Book. A generous two-finger swipe that should scroll by several thousand pixels is in your demo (when further instrumented to keep totals of deltas) only perceiving several dozen pixels of delta.

In short: you mustn’t ever reset the scroll position.

Re: Luckysheet, an open-source spreadsheet

#102

Post by boring_twenties »

alpaca128 wrote: post #65
asah wrote: post #57

Earlier quoted context omitted.

No installation Multiple tabs/windows Don't leave the browser Works-at-all on multiple platforms incl mobile Deep linking / sharing / bookmarking App freezes are less common (on network access) and easier to manage when they happen - obviously this is anecdotal and not universal.

Registration/Login required(I'll take the installation over that in many cases) No properly working (or even implemented) keyboard shortcuts; I just tried, Google Sheets tells me to use Ctrl+C etc. but it doesn't do anything, and what's even worse is that the menu item for "insert" doesn't do anything either because Google wants to force me to use the dysfunctional keybinding...thanks I guess Usually no right click +…

> use Ctrl+C etc. but it doesn't do anything

Did you set clipboard events to false in about:config?

Probably. After all, if you don't set that, lots of sites will do stupid things like prevent you from copying, or pasting into certain fields.

But it will break things like Google Sheets.

Re: Luckysheet, an open-source spreadsheet

#103

Post by rwmj »

mthoms wrote: post #97
chrispsn wrote: post #69

Earlier quoted context omitted.

When you say 'has the functionality of a spreadsheet but looks nothing like current spreadsheets', what do you mean? I am working on Mesh Spreadsheet. It gives you a spreadsheet UI that writes code as text. It will likely use k9 as the formula language once it matures, but: - you can try the JavaScript prototype at this link: http://mesh-spreadsheet.com - you can see a proof of concept video using k here: https://www…

Hi, what's K9? My Google searches in combination with "formula and/or language" gave me only dog related results.

I believe he is talking about: https://shakti.com/ which confusingly is a version(?) of K https://aplwiki.com/wiki/K hence K9.

Re: Luckysheet, an open-source spreadsheet

#104

Post by robbiejs »

chrismorgan wrote: post #100
robbiejs wrote: post #89

Earlier quoted context omitted.

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 mobil…

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 Li…

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?

Re: Luckysheet, an open-source spreadsheet

#105

Post by robbiejs »

blntechie wrote: post #90
robbiejs wrote: post #89

Earlier quoted context omitted.

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 mobil…

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…

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.

Re: Luckysheet, an open-source spreadsheet

#106

Post by smaddox »

chrismorgan wrote: post #53

I will keep saying this every single time some one gets this wrong (which is at least 49 times out of 50): the only way to handle scrolling properly on the web is for your scroll events to fall onto a real scrollable area, and to observe the effect it has (e.g. apply the scroll position to what you’re rendering with). This can be tricky to achieve well when you have dynamic content that the mouse needs to be able to…

The way I solved this in my own (not finished) web-based spreadsheet app is to have a scrollable div positioned over the canvas and to size the transparent div contents to the width/height of the sheet. Then I register scroll event handlers and redraw the canvas appropriately when the scroll changes. I think this is how Google sheets works, although it's a bit difficult to tell for sure.

It behaves exactly how you would expect. It even properly handles clicking and dragging to the edge of the screen, which I did not expect prior to implementing it.

Re: Luckysheet, an open-source spreadsheet

#107

Post by cookiengineer »

chrismorgan wrote: post #99
cookiengineer wrote: post #92

Earlier quoted context omitted.

> 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…

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...

Re: Luckysheet, an open-source spreadsheet

#109

Post by microcolonel »

chrismorgan wrote: post #101
microcolonel wrote: post #83

Earlier quoted context omitted.

There are some intricacies about when to reset the scroll position, if ever. Here's one way: https://codepen.io/xorgy/pen/yYdVoY

This way is very, very wrong in how it resets the scroll position: it essentially assumes synchronous scrolling, and falls apart completely if that isn’t the case—and it hasn’t been for some years. By “synchronous scrolling” I mean that reading scrollTop gets you the true current value, and that setting scrollTop sets the value immediately. These used to be the case, but scrolling is handled off-thread now, so the va…

On Chrome based browsers on Android at least, it works perfectly fine with momentum. It even does accumulating momentum, I can easily get it up to 6,000px/frame.

Does this not work properly on iOS?

Re: Luckysheet, an open-source spreadsheet

#110

Post by chrismorgan »

robbiejs wrote: post #104
chrismorgan wrote: post #100

Earlier quoted context omitted.

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 Li…

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.

Post reply on HN