Please make your table headings sticky | Hacker News Reader

Please make your table headings sticky

btxx.org

354 pointsaragilar73 comments

I'll give you sticky headers on one axis, but am still waiting for the day that CSS supports them on both axes: https://github.com/w3c/csswg-drafts/issues/8286

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.

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.

Huh? I know of at least three table frameworks with sticky rows & headers (MUI X and AG Grid, Ant.design).

And there are more virtual-list libraries than I can count my.

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.

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.

[1] https://developer.mozilla.org/en-US/docs/Web/API/ResizeObser...

https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-marg...

Ohh, thank you very much. I was avoiding sticky headers exactly because of this problem

Or make a paginated table? This sounds like a problem made by having infiniscroll pages.

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.

GP said they are lazy loading table content on scroll, so they already lost Ctrl+F and client-side sorting anyway.

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.

In case you're one of the people implementing this and want your header's borders to also stick, you can do something like this

    table thead:before {
      content: '';
      position: absolute;
      width: 100%;
      top: 0;
      border-top: 2px solid;
    }

    table thead:after {
      content: '';
      position: absolute;
      width: 100%;
      bottom: 0;
      border-bottom: 1px solid;
    }

I wish table headers did this automatically. If devs do the extra work to use <th> tags then this is likely the behavior they already want.

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.

> Just install a browser plugin that allows you to load a custom stylesheet on every page.

why have everyone do extra work when one person could do it for everyone else in about the same amount of time that it would take one client to do?

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.

So please, let's not do this.

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.

Perhaps AI can automatically figure out how to do it for each page?

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.

And at the command line: headers to stderr, body to stdout.

Without it you get this behavior:

  > heights | sort -k2 -nr
  George  186
  Wally   173
  NAME    HEIGHT

But if the headers bypass stdout then you get this instead:

  > heights | sort -k2 -nr
  NAME    HEIGHT
  George  186
  Wally   173

Which one works best here ? Headers to stderr, or headers only if stdout is a tty ?

...unless you're writing to a file, in which case you'll require a couple tries and a higher quantum of shell comprehension.

This is a persistent limitation of the in-band text-only model. But I think this misuse of STDERR would be more confusing than helpful.

If `heights` was a file, you could do this:

  % head -1 heights ; sed 1,1d heights | sort -k2 -nr

If `heights` is an executable that would be expensive to call twice:

  % heights > /tmp/heights ; head -1 /tmp/heights ; sed 1,1d /tmp/heights | sort -k2 -nr

Or you could pipe to `awk`, etc.

Granted, these other options are less convenient, but they are also less surprising, and they work even if the executable creator has different ideas.

Sometimes you gotta do what you gotta do.

> heights | (sed -u 1q; sort -k2 -nr)

does the right thing.

(from https://stackoverflow.com/a/56151840)

This didn't work for a long time. Chrome previously disabled position sticky on thead and tr elements: https://issues.chromium.org/issues/41303743

I remember the browser support matrix showed almost all green when it didn't work for tables in Chrome.

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.

Some of us would rather say "please don't": https://news.ycombinator.com/item?id=32998091

What's bad about the sticky property?

I want a dumb document. I don't want the thing where the header gets in the way of my clicking as I scroll.

If we get OPs dream, it wouldn't.

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.

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.

Don't archive the web by taking screenshots?

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.

Firefox can screenshot the entire page: https://support.mozilla.org/en-US/kb/take-screenshots-firefo...

Thanks for the tip. Also I completely forgot you can screenshot specific HTML elements in the Inspect panel with a right-click and "screenshot node".

Late Edit: unfortunately Firefox' screenshot feature seems to have a maximum size, beyond which it just silently truncates the output.

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

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.

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.

the CodePen looks better if top is set to offset the border (i.e. -1px instead of 0). It avoids the table body from bleeding above the header.

Compare: https://codepen.io/bradleytaunt/pen/bGZyJBj

With: https://codepen.io/alokmenghrajani/pen/ExMBQow

Instead of sticky headers, I would suggest using a limited viewport height, so that the headers always remain visible.

Like in DataGridXL (https://datagridxl.com) disclaimer: I am the creator

Just a thought: This is very difficult to navigate without a pointing device (e.g. using the keyboard.)

Not sure what you mean. Keyboard controls are like Excel. What do you find difficult?

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:

Scroll the table down and up.

Scroll the table right and left.

Select some text in the table and copy it.

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)

I'm not trying to criticize you, but I've never been a fan of this on mobile. I think the content should scroll with the page.

Perhaps it's because of the scroll snapping? Version 3 of the product will have smooth scrolling, which is more natural on mobile.

Make a browser extension that stickys all table headings :p

All fine and dandy until you try to add horizontal scrolling to the table :(

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

I had a fun time generalizing sticky headings so they work for forms and nested tables: https://vimeo.com/566181649 . Though that was in a Java app.

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.

Is there anything in the spec that says any specific element disappears from view when you page down?

It would break a lot of existing content to change something like this, unfortunately.

No it wouldn't.

...it absolutely would, yes. Tables are used everywhere, including for positioning stuff.

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.

Looking at you, Confluence.

... videos, not inline examples?

I'm not sure it's worth caring about. Either way seems to communicate the problem perfectly. They provide a playground with code.

But my Canadian data rate...

Perhaps because 4% of user agents don't support it.

CSS sticky headings (the solution) won't work on the user agents that don't support it anyway, so they wouldn't be missing out. :)

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.

Because the videos show the issue with out requiring instructions to the user on how to repo the issue being addressed.

I've done this myself (usually with a gif though) because if I leave it as a exercise for the user to fiddle with 15% of them won't understand it.

Reply on news.ycombinator.com