One of the most challenging things I have done was when I got contracted to make both column and header sticky. Easy enough with a standard table, but this was in some wild VueJS extended third party library dynamic table with generated CSS as JS. It took me ages just to unravel where all the different CSS and JS actually came from and then I had to work around via overriding JS class functions and generated CSS etc.
I felt really bad for the client because of how long it took. It also made me really careful with deciding on libraries when in Vue/React codebases. It's a very self-inflicted wound to require that much effort to do such a simple task. It's a table dangit, a HTML primitive, why am I like three JS classes deep and importing CSS as JSON?
We design said they wanted row expansion. Then buttons in some cells based on rules open modals.
Other cells have hover tooltips. And we need sort. Must have sort. And one of the table columns has editable values. But the edited value doesn’t affect the sort. It should affect the filter though. Did I mention we need filters? Also I need two sticky columns unless the user is a BobRole, then they should have 3 sticky columns and shouldn’t see column 9.
The table will have 50,000 rows with pagination. Pagination must respect the sort and filter obviously.
That's where ecosystems really matter. These kinds of use cases are well solved in places like C# desktop toolkits, where stable conditions allow ecosystems to build up and companies willing to drop thousands on licenses for UI toolkits inject plenty of cash. The javascript ecosystem on the other hand is so cash-strapped, frequently disrupted, and splintered across frameworks that libraries rarely reach the maturity necessary for complex situations. Even virtual scrolling is a rarity. So everyone just develops what they need in-house, and the next project has to start from scratch.
That is an interesting perspective, I had never considered the JS ecosystem to be cash strapped but I see what you mean. Aside from big institutions supporting some of the leading frameworks there is a limited amount of paid products and an expectation that things be open sourced. JS has a lot of man hours in its ecosystem but they are into thousands of individual projects, not holistic frameworks.
Oh gosh I forgot about the row expansion and sort, and infinite load coupled with the sort in my case. Slightly better because the user just got flicked to the top of the table if they sorted anything.
I've been watching the issue that spawned this one for maybe 8 years now. It's by far my biggest annoyance about the CSS spec. Sometimes you just need a gigantic data table, and you want that to be sticky top and overflow-x auto. Sorry, too bad, you have to pick one of these.
confession: I somehow make just functional web apps with near zero CSS knowledge. I recently tried to make the header sticky on this ~20k row monstrosity: https://www.datasciencemeta.com/rpackages
My first port of call was bootstrap table classes (hoping for a class="table table-header-sticky") but there's nothing of the sort. I fiddled with suggestions from stack overflow, GPT and codepen in ~20 minutes only got sticky headers working with weird side effects on the rest of the table.
But in 2 minutes with the codepen from this article, I have it working. Pushing to prod now. Thank you!
You would think it's that easy to make the table heading sticky with just one `position: sticky;`, until you decide to do anything with the table content.
I have a table with sticky head. Then I decide to add a memory feature, where if user scrolls the table body, and leaves the page, I'd save the index of the first visible row, and restore the scroll position when user comes back. I noticed that every time the restored position is always about one row too downward. For instance, when I want to restore to row 5, it restores to row 6 plus a few pixels. Turns out, once I turned the thead semi-transparent, I can see row 5 was indeed at the top of the table, but the thead just overlaps on top and making it look like row 6 is the first visible row.
I told myself, no problem, I just modify the scroll position to be aware of the thead's height. It worked fine at first, but from time to from it'd still be off a few pixels. Turns out, because the table is huge, I'm doing lazy loading upon the scroll event. And because I'm using the default automatic table layout (instead of the fixed layout), sometimes certain head cell becomes too narrow and word wraps, thus increases the whole head's height. The final solution is to create a ResizeObserver[1] on the thead element and dynamically adjust the scroll position if its height changes.
Pagination should only be used if the dataset is yoo big to be reasonably rendered as one page, as it prevents you from using Ctrl-F or sorting the table by different columns Client-Side.
Or... you do all that sorting and searching server side as well. Which... I've got mixed feelings on this, and tend to not do it unless 1) it's an absolute must and/or 2) I'm using a toolkit that already supports it. Without those, I'd tend to just throw everything down and let the client be able to do all it's sorting/filtering/etc at the client.
Just install a browser plugin that allows you to load a custom stylesheet on every page.
Unfortunately I'm seeing an increasing number of websites using 500 <div>s with 45 nested layers of <div>s within each <div> to create a table instead of <table>s so it wouldn't work on those.
My take is that default styling is already bloated enough. Every-time I need to start out a new project, the first thing I do os to reset default styles.
Also, we already have a situation where different browsers have different defaults leading to an overall worse UX of the web.
Note that this requires giving the plugin permissions to read and write to all pages you visit. Browser extensions are routinely compromised by bad actors to steal banking passwords or bitcoin wallet keys.
I use tampermonkey, but I have it restricted to just one domain, which it complains about every time chrome is restarted.
This definitely seems like the sort of change that would break things in unexpected ways. I think the main reason is probably that a lot of websites used tables to do grid layouts before CSS grid was a thing, so having sticky headings would break this. It's really a huge failure of the semantics of HTML that a table is viewed as "an arbitrary grid of elements" rather than "a way to display tabular data".
Back when we'd use HTML tables for the entire layout. CSS wasn't a big thing and it couldn't do what you'd want. Even today plenty of emails are done via table hacking. I think your overall point is correct but the origin of the behavior, both human and web layout, are older than that.
Yeah surprised too this is this simple now. Granted it was a while ago I needed this, but you had to add random cruft to the html and CSS to make this work across browsers. Which somehow didn't even surprise me because that's how webdev works in a nutshell.
For Web pages generally, absolutely. I'll often delete any sticky elements using uBlock Origin, as that's faster than writing a Stylus style (though I've had reasonably good luck with generic styles applied to sites as well).
But TFA is about data tables with a sticky header column, a suggestion which really is genuinely useful.
NB: for examples of HTML tables with quite useful features, see Wikipedia / Wikimedia, desktop site.
Sticky headers and often a sortable fields functionality.
I've long wanted to see browsers offer modest spreadsheet-like features for tables. At the very least, the ability to sort, filter, summarise, and compute some simple statistical moments (mean, median, mode, standard deviation, possibly percentiles) of numeric ranges. Pivot tables might also be neat.
No reason this couldn't be a basic browser affordance.
That's about sticky headers of web pages as a whole. For tables it's a whole different thing. I absolutely hate looking at a table with a dozen columns with numbers and then not knowing what is what as soon as I scroll down a bit.
Same, I can't stand sticky headers, especially on anything involving longform text content. They also make web archiving significantly harder as scrolled screenshots cant be easily stitched together anymore to get the whole page.
What other way is as convenient and available but better?
Printing as PDF doesn't save the content exactly as it's shown in the browser and a plugin I used for a while in the past was pretty unreliable.
Screenshots work on any device with a modern browser and usually I don't want to capture the entire page anyway but just specific interesting parts.
I understand the sentiment but at some point you're asking for the underlying CSV file. In my opinion a little gear icon which lets you toggle sticky headers and other formatting options and downloadable data as plain text is ideal but good luck standardizing such things.
> the header gets in the way of my clicking as I scroll
Sounds like your problem are not sticky headers but the "smart" semi-sticky ones that hide or show dynamically as you change scrolling direction, hiding content in exactly the place the user is looking at.
Open your page, and try doing these actions without touching your mouse. Some are just awkward, requiring a lot of Tab key. Some I have not figured out at all:
I appreciate your feedback. However, I must admit that I still a bit in the dark about what is awkward about it.
The component is used by a million+ end users and copies traditional Excel/Google Sheets controls.
Are you familiar with those programs?
DataGridXL is an Excel-like component for editing cell values, rather than a table component for selecting rows.
I am curious though if the component is somehow not working like Excel for you... will you perhaps take the time to do a screen recording? I am curious to know what you find awkward, as I especially take pride in the usability of the component. (robbert@datagridxl.com)
There are nice little headings in the video. But sometimes there are larger (multi-line, with paddings) headings, or simply broken ones (e.g., custom fonts with icons that don't load), and such headings are more annoying than useful to have sticky. Especially with pages that also show their headers and footers at all times, leaving little space for the content. Which makes it one of those features that should be used with care (while it is occasionally useful, and so is raising awareness about it).
No, don't. The kewl design crowd will insist that the tables and rows be borderless and that the scroll bars disappear. You won't be able to see if the top rows of the table are showing.
There's nothing in the spec that says table headings disappear from view when you page down. This is a problem with your WWW reader. Nothing about this requires authors/publishers to be in the loop on this, each applying their own one-off hacky attempt to "fix" this. They really shouldn't be.
Actually think though the things you're saying when you say them. People generally don't put thead elements in tables that are used for positioning. Even ignoring that, there is no definition of "break" besides the most contrived and tautological for which allowing people to see table headings would break anything. Bolstering low-effort concern-trolling as if it's high-value commentary (i.e. well-received middlebrow dismissals) is known to be a problem on HN, and you're not making it better.
Thats not really an issue in this case. The only browsers not supporting it are ie11 and opera mini. (And a thing called QQbrowser which I confess I've never heard of.) I'm guess the 4% of traffic is largely ie11.
If you are browsing the Web today with ie11 then there's a lot of css that isn't going to work right.
And the impact of not supporting sticky is invisible - the table just works as it does now.
So there's no -techical- reason not to use it. At this point it's either a cosmetic choice (mostly for overflow reasons) or unawareness of its existence.
