Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
61–70 of 108 posts
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#62Earlier quoted context omitted.
Generally I agree, however even some DOM-based implementations of spreadsheets (and similar applications with very long lists of things) break "find in page" due to them only rendering visible cells for performance reasons. For example, Google Sheets hijacks command/control-F to show their own search for this reason.
Also because Google Sheets is a canvas implementation, not DOM
That said, X-Spreadsheet does also use DOM for some text interactions at least—seemingly much less so than Google from what I can initially/briefly see though.
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#63I think a description of why canvas was used would be nice in the README. My (probably naive) view is that browsers are pretty good at table-ish layouts so it’d be great to know why canvas was chosen.
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#64This strongly goes against the best practices for Canvas: https://www.w3.org/TR/2dcontext/#best-practices
Yes, but it may be worth effort. See for example this editor: http://evanw.github.io/sky/ and paste there even tens of thousands long text. It will work super smooth, like Sublime Text does. If only browsers provided low level APIs for text, font calculations and accessbility (what they already support internally), those kind of editors would make a lot of sense.
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#65Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#66I think a description of why canvas was used would be nice in the README. My (probably naive) view is that browsers are pretty good at table-ish layouts so it’d be great to know why canvas was chosen.
I've tried to do what OP did more than a couple times using native HTML tables (for the same reason you suggest) and I've found it to be nearly impossible. Trying to force a table to keep columns one specific width and not jump around every time you change one of the cells is somewhere between an exercise in futility and not worth the pain. I think OP went the right way here.
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#67Earlier quoted context omitted.
If by table-ish layouts you mean using the element to render something like this then browsers might be OK at it but the woefully inadequate to do anything more than the most basic table renderings. Virtual scrolling or frozen rows/columns is a lot of manual work to do on top of a .
Plus I crashed safari on an ipad with a simple page with a table of a few tens thousand rows.
Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#68Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#69Re: Show HN: X-spreadsheet – A JavaScript canvas spreadsheet for web
#70by its definition is essentially an with its content (pixmap) modifiable from script side.
Better solution would be for browser to support immediate mode drawing. Like in my sciter (https://sciter.com) where you can define immediate mode painting methods (Element.paintBackground|Content|Foreground|Outline):
var elGrid = …
elGrid.paintBackground = function(gfx) {
for(var r in ROWS )
gfx.hline(0,r * cellh, width);
for(var c in COLS )
gfx.vline(c * cellw, 0, height);
}
That paintBackground callback is invoked as a part of WM_PAINT window handler and with the same Graphics that window uses for rendering the DOM - no intermediate bitmaps.Such model requires slightly different Graphics architecture than what is used by browsers. At least Path, Brush and TextLayout classes need to be added in order all that to work effectively.
Or to redefine all that on top of WebGL but that will be weird - browsers already have all 2D primitives (Direct2D, Skia, Cairo) implemented natively.