Thanks, but I am not looking for the “rough” solution, I found plenty of those online.
I can accept if there is no clean solution (in the sense of something that does not rely on fixed dimensions for elements, JS, browser-specific hacks, etc), then I just don’t implement this feature — so that would also be useful information.
TableView does not actually support editing (which indeed is a bit confusing as you can edit the field in the spreadsheet but that has no effect on the underlying Julia data). I had created a TableWidgets package for this (that I can’t upgrade yet as it depends on JuliaDB), but I was wondering whether it’d be better to do a more lighweight version of generally useful widgets for tables (for display / filtering / manipulations) that only depends on basic packages .
You could combine this with a seperate header table instead of using position:fixed on the top row
It would be pretty nice to have a css column toggle/select but that one might just be easier on the julia side
My PR to TableViews doesn’t include any editing capabilities and should soon be a pretty good option to display arbitrarily large datasets.
A non-JS fallback might be useful – do note that it’s usually not a good idea to display many (> 500 maybe?) rows in pure HTML though so it’d probably be good to limit the number of displayable rows.
I just tried 100_000 rows with BrowseTables.jl, and it displays just fine in about 2 seconds (Firefox 64.0b2, Linux, just a normal 3-year old laptop, I have about 30 other tabs open). This is precisely why I am keeping it simple, with a relatively clean HTML.
github: You can’t comment at this time. -Posting here instead
It did make visible a few other glitches with the position:fixed approach, and could be handy for database-like linked tables. I’m not super-familiar with how github does it’s pr’s and branch merges yet, so that was a little unexpected. Any thoughts on the Scrolltables.css approach?
Github is apparently experiencing a problem, I am seeing this too in other repos (I got a message that you closed the PR, but it is still open). I hope this is not becoming systematic.
Regarding the PR: as I commented on it there, I am reluctant to specify width manually, as it would sacrifice compactness. Lacking that, I think the misalignment remains, isn’t that so? Also, I don’t want multiple tables in a file, that’s what browser tabs are for.
Misalignment is fixed by position:sticky, and the widths are still there but seem to shrink when required in firefox at least (~30 cols with short headers and data -expanded to 49 - shrunk). I think we’re both happy enough with our seperate versions