5 ms·

Sticky table headers and columns: yes, yes, yes. That is very important for usability, and currently hard to do properly. If I could just add a layout attribute

by mbrock 13y ago

Sticky table headers and columns: yes, yes, yes. That is very important for usability, and currently hard to do properly. If I could just add a layout attribute to a THEAD or COLGROUP, my life would be significantly easier. We've spent a lot of time implementing this ourselves for a data table containing lab analysis values. It's a big requirement from our customers. You can imagine it's pretty important to be able to match rows and columns (sample types and dates) correctly when you're looking at these values. The planning meeting about this was pretty funny. Boss: "So, we'll just make the headers fixed, should be easy, right?" Developer: "Heh-heh... Yeah, we could probably get that working decently in just a couple of weeks. We'll have to test it in all the browsers, of course, and do performance tests with big data sets. It's possible that we might not be able to get it to work well enough on all platforms, so we should have a backup plan." Boss: "Sigh. This would be so much easier in Visual Basic..."

tluyben2 13y ago
The boss is right though. This (and a lot of other things) is much easier in almost every other GUI lib I worked with. Some things like documents (flowing text with images etc) are easier in HTML, but that is what it was made for.
- mbrock 13y ago
  It's a little sad how basic presentation of tabular data is so tricky. That should be an essential part of a document-oriented technology. I guess a good solution would be a little too complex.
  - jalfresi 13y ago
    I've never understood why the text/csv mime-type is not recognised by browsers: you should be able to embed a CSV into a HTML page using the <object> elements, much like an image. Then the browser could handle things like fixed headers etc.
    - lambda 13y ago
      It's not too hard to embed it yourself; here's a quick proposal I did when the idea of embedding CSV in a custom element was being discussed on the WHATWG list: http://ephemera.continuation.org/csv.html http://ephemera.continuation.org/csv.html The issue of fixed headers is a styling issue, not an issue of what embedding types are supported; and that is solved by the "position: sticky" CSS attribute that this link discusses. There has been an experimental WebKit implementation of this for a while, this now adds an experimental Gecko implementation. Hopefully this will be standardized soon and available in non-experimental form.
inthewind 13y ago
The thing is though. That really the semantic markup is already there in the table. So I don't see why the browser in this case can't just help you out a little. You could click the table, and the whole thing pop out in a 'table viewer'. Or the browser could use a tool tip, and ghost the headers on scroll or something. If I want a fixed header on a table. Couldn't I just fix the body height on the tbody, and use an overflow: scroll, to achieve the same effect? or am I missing something? Forgive me as I'm still unsure as to what position:sticky actually means. Is it to keep the headings on screen?
- mbrock 13y ago
  Setting an absolute position on the THEAD works (except, I think, in old IE), but only with fixed column widths. The usual hack involves using JavaScript to keep the columns in sync. The header cells end up being layouted separately from the body cells, and so their widths are not constrained together. Actually, I'm not sure if sticky positioning is different in this regard... This property might not solve the problem we ran into. In any case, a sticky header is different from an absolute header, because it doesn't require a separate scrolling container. You just scroll the page, and the header follows along, until the table scrolls out of the viewport.
- grimtrigger 13y ago
  Would make a nifty niche browser extension I imagine.
Amadou 13y ago
I'm wondering if, from UX perspective, in most cases it would be sufficient to draw the headers based on the mouse position. If the user hovers the mouse over a row in the able that causes the headers to pop-over one (or more) rows above the mouse position in a tool-tip like fashion (correctly aligned with the columns, of course).
- peterkelly 13y ago
  That won't work so well on a tablet
- mbrock 13y ago
  Hmm, perhaps in some applications. In my example, it's nice to be able to scroll down to the interval of interest, and then just sit back and look at the data, not having to make sure the mouse cursor is in the right place.
pjmlp 13y ago
This type of broken experience compared with what is possible in native applications is what makes me always take native projects over web ones, when given the choice.
- talmand 13y ago
  It's not a broken experience. It's attempting to make something perform in a way it was not designed, nor intended, for. Just because a Honda Civic can't compete in an F1 race doesn't mean the Civic is broken.
  - Pxtl 13y ago
    It's a table, for the intent of displaying tabular data. Headers are an essential component of reading a table. If the headers do not remain visible after scrolling down, the table is not displaying useful information. It is a broken experience, and a defect in the HTML concept of a "table". Honestly, we have to stop defending these terrible web technologies we're saddled with. We use them because they're the only universal-standard client application engine. Not because they're good.
    - taf2 13y ago
      I don't think they're all that bad either... I mean if you're using IE then sure you can say they are terrible. But in the other browsers - they're actually pretty good. There is room for improvement - but for what we get it's pretty incredible. And you can implement headers that follow you in a table - it just requires writing some code, which you can say is bad.. but then if you go off and write in a native application I"m sure you'll be writing a lot more code than I will in my web app... the issues usually boil down to the client e.g. IE or the lack of native extensions in WebCore preventing the web app from performing better... yeah.. that's my two cents...
    - talmand 13y ago
      So, an always visible table header is a requirement for correct viewing of tabular data. That means every book ever printed, or long pages for that matter, that had tabular data presents a broken experience. I would think that people who relied on books before computers came along would disagree. HTML provides for a means to view tabular data and performs that function in a minimal and acceptable manner. People moving the goal posts on the requirements does not mean the current implementation is "broken" nor "defective". It simply does not perform an extra feature that people would like to have today. I also don't believe I was defending anything, I was simply disagreeing with an unfair criticism against a technology because it wouldn't do what it wasn't designed to do based on current expectations. The simple fact that HTML/CSS/Javascript allows for it to be extended and expanded shows it is not a defective means of displaying information. It means that there's the occasional lag in updating the specs to meet people's current expectations. Blame the people not keeping the spec up to date with current expectations and not the spec. Once position:sticky is in common use I suppose we'll wait until the next new expectation of functionality appears that means something is "broken". HTML/CSS/Javascript is good in many ways, but I agree it is not perfect and it never will be.

by mbrock 13y ago

tluyben2 13y ago

The boss is right though. This (and a lot of other things) is much easier in almost every other GUI lib I worked with. Some things like documents (flowing text with images etc) are easier in HTML, but that is what it was made for.

mbrock 13y ago
It's a little sad how basic presentation of tabular data is so tricky. That should be an essential part of a document-oriented technology. I guess a good solution would be a little too complex.
- jalfresi 13y ago
  I've never understood why the text/csv mime-type is not recognised by browsers: you should be able to embed a CSV into a HTML page using the <object> elements, much like an image. Then the browser could handle things like fixed headers etc.
  - lambda 13y ago
    It's not too hard to embed it yourself; here's a quick proposal I did when the idea of embedding CSV in a custom element was being discussed on the WHATWG list: http://ephemera.continuation.org/csv.html http://ephemera.continuation.org/csv.html The issue of fixed headers is a styling issue, not an issue of what embedding types are supported; and that is solved by the "position: sticky" CSS attribute that this link discusses. There has been an experimental WebKit implementation of this for a while, this now adds an experimental Gecko implementation. Hopefully this will be standardized soon and available in non-experimental form.

inthewind 13y ago

The thing is though. That really the semantic markup is already there in the table. So I don't see why the browser in this case can't just help you out a little. You could click the table, and the whole thing pop out in a 'table viewer'. Or the browser could use a tool tip, and ghost the headers on scroll or something. If I want a fixed header on a table. Couldn't I just fix the body height on the tbody, and use an overflow: scroll, to achieve the same effect? or am I missing something? Forgive me as I'm still unsure as to what position:sticky actually means. Is it to keep the headings on screen?

mbrock 13y ago
Setting an absolute position on the THEAD works (except, I think, in old IE), but only with fixed column widths. The usual hack involves using JavaScript to keep the columns in sync. The header cells end up being layouted separately from the body cells, and so their widths are not constrained together. Actually, I'm not sure if sticky positioning is different in this regard... This property might not solve the problem we ran into. In any case, a sticky header is different from an absolute header, because it doesn't require a separate scrolling container. You just scroll the page, and the header follows along, until the table scrolls out of the viewport.
grimtrigger 13y ago
Would make a nifty niche browser extension I imagine.

Amadou 13y ago

I'm wondering if, from UX perspective, in most cases it would be sufficient to draw the headers based on the mouse position. If the user hovers the mouse over a row in the able that causes the headers to pop-over one (or more) rows above the mouse position in a tool-tip like fashion (correctly aligned with the columns, of course).

peterkelly 13y ago
That won't work so well on a tablet
mbrock 13y ago
Hmm, perhaps in some applications. In my example, it's nice to be able to scroll down to the interval of interest, and then just sit back and look at the data, not having to make sure the mouse cursor is in the right place.

pjmlp 13y ago

This type of broken experience compared with what is possible in native applications is what makes me always take native projects over web ones, when given the choice.

talmand 13y ago
It's not a broken experience. It's attempting to make something perform in a way it was not designed, nor intended, for. Just because a Honda Civic can't compete in an F1 race doesn't mean the Civic is broken.
- Pxtl 13y ago
  It's a table, for the intent of displaying tabular data. Headers are an essential component of reading a table. If the headers do not remain visible after scrolling down, the table is not displaying useful information. It is a broken experience, and a defect in the HTML concept of a "table". Honestly, we have to stop defending these terrible web technologies we're saddled with. We use them because they're the only universal-standard client application engine. Not because they're good.
  - taf2 13y ago
    I don't think they're all that bad either... I mean if you're using IE then sure you can say they are terrible. But in the other browsers - they're actually pretty good. There is room for improvement - but for what we get it's pretty incredible. And you can implement headers that follow you in a table - it just requires writing some code, which you can say is bad.. but then if you go off and write in a native application I"m sure you'll be writing a lot more code than I will in my web app... the issues usually boil down to the client e.g. IE or the lack of native extensions in WebCore preventing the web app from performing better... yeah.. that's my two cents...
  - talmand 13y ago
    So, an always visible table header is a requirement for correct viewing of tabular data. That means every book ever printed, or long pages for that matter, that had tabular data presents a broken experience. I would think that people who relied on books before computers came along would disagree. HTML provides for a means to view tabular data and performs that function in a minimal and acceptable manner. People moving the goal posts on the requirements does not mean the current implementation is "broken" nor "defective". It simply does not perform an extra feature that people would like to have today. I also don't believe I was defending anything, I was simply disagreeing with an unfair criticism against a technology because it wouldn't do what it wasn't designed to do based on current expectations. The simple fact that HTML/CSS/Javascript allows for it to be extended and expanded shows it is not a defective means of displaying information. It means that there's the occasional lag in updating the specs to meet people's current expectations. Blame the people not keeping the spec up to date with current expectations and not the spec. Once position:sticky is in common use I suppose we'll wait until the next new expectation of functionality appears that means something is "broken". HTML/CSS/Javascript is good in many ways, but I agree it is not perfect and it never will be.