Demystifying tables (cells inside; borders outside) | Hacker News Reader

Demystifying tables (cells inside; borders outside)

lakesare.brick.do

64 pointslakesare21 comments

Seems like modern web developers don't use tables as much as they should. I blame the "missing generation" for this. Tables used for layout was considered so bad, that many stopped using tables for tabular data.

To explain more, consider this evolution of tables based for layout

1. Early 90s/2000s: Tables used for layout as no good alternatives were available

2. The "popular" kids hated tables for layout and tried to use floats etc. A 3 column layout using floats was considered "the holy grail", because it was so hard to get it to work. Most developers continued using tables until Bootstrap and other frameworks managed to take some of the pain away

3. Flexbox is introduced as an alternative to floats, but with its own issues.

4. CSS grids are finally here, after only 30 years of waiting for it and we can finally get a 3 column layout working without too much dark magic.

To me it seems that they years between 2 and 3 was kind of "lost", where developers got the impression that tables were bad even for tabular data. I have seen so many developers display tables as a collection of divs, or just giving up and using a picture of a table instead. The losers are of course accessibility and the semantic web.

Now it seem developers are rediscovering tables due to the superior accessibility they provide and they are "allowed" by the hipsters to actually use tables for tabular data again.

Next step: Maybe realize that there are other tags than h1 and div? One can only dream.

Mobile view of tables is the worst, since they almost always horizontally overflow the narrow screens. I suggest that's another reason tabular non-tables have stuck around.

Nowdays, with `display: contents` (on the tbody/tr) you can use `display: grid` to do the layout for your table, too, making it easier to make the table responsive.

CSS lets you do other fun things to tables, too. For example https://ffoodd.github.io/chaarts/pie-charts.html uses tables, but does not display like a table.

Wouldn't table markup be the correct semantic designator for tabular data? Plus the plugins that work with tables, the ease of copying tables from the screen to spreadsheets, that screen readers know what tables are, etc.

Yeah, I'm not saying don't use tables. Do use tables, they're great for accessibility, but don't feel tied to using table layout; CSS has some great alternatives now that preserve the HTML structure of the table, but display it differently.

Have you ever done a 'View Source' on the HN comments page?

The css alternative to <table> was display:table which have existed for ages.

> 2. The "popular" kids hated tables for layout and tried to use floats etc. A 3 column layout using floats was considered "the holy grail", because it was so hard to get it to work. Most developers continued using tables until Bootstrap and other frameworks managed to take some of the pain away

Ha ha ha! Yeah, in hindsight I should have skipped this "right way" bandwagon and stuck with tables until this phase was over. I wasted a lot more time screwing around with "float" than I did fixing up table layouts. Even if it would have made me significantly less cool.

One point which is missing from this article is how information should be aligned and formatted within cells. This is an underrated feature which can really improve table readability.

For example, right aligned numbers make skimming by size a bit easier.

There's more common UX guidelines but I can't remember them off the top of my head.

Sounds interesting, please link me to those guidelines if you stumble upon them!

Data Looks Better Naked: Clear Off the Table - https://www.darkhorseanalytics.com/blog/clear-off-the-table

Hah, it basically goes into denormalisation!

This certainly looks prettier than the initially shown full-fledged table structure, however I'm having more trouble reading it - it makes me slightly uncertain what text belongs to what row, and whether I properly track the row lines with my eyesight.

The "improved" bar chart looks atrocious. If these are the articles modern designers are reading, its no wonder the state of design is what it is now.

interested too

For anyone interested in building data tables for the web or ERP systems, here are the resources that I have collected (in no particular order):

- https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1...

- https://pencilandpaper.io/articles/ux-pattern-analysis-enter...

- https://www.nngroup.com/articles/data-tables/

- https://www.csescienceeditor.org/article/best-practices-in-t... (this one is about print, not web)

- even more guidelines: https://stephaniewalter.design/blog/essential-resources-desi...

Thanks for sharing

Do Share when you have a moment.

Others I have (personal) - Alignment of Headers should match that of content (centre aligned headers = centre aligned content) - Headers should be bolded or another color - Subtotal & grand total should be bolded - Keep same font for both headers & content - Try to keep columns and rows equally sized and spaced - Table heading at the top (IMO) - Avoid using cell (0, 0) that the article talks about

All of the above IMO aids in simplifying the table and hence makes the content stick out more. But granted they are more design principles vs. UX so I too would be keen to learn more about UX guidelines to apply

"There's more common UX guidelines..."

I can recommend the table guidelines from this 2018 conference talk. The advice has not dated and the presenter shows before-and-after examples of making tables easier to read.

The section on tables starts at the 11.47 minute mark in the talk:

Web Typography (2018) | Set tables to be read: https://youtu.be/hbIZX6tE9JY?t=707

Even better, with the following, noscript/basic (x)html with basic html forms can do wonders, that even with excrutiating simple and small web browsers (which do not implement css or at best very partially). Tables are actually semantic layout.

https://webaim.org/techniques/tables/

That final example with sugar-y (so to speak) grouped headers contradicts prior definition of "normalized table". First "normalized" example explicitly shows that grouping happens exclusively by using text repetition in adjacent headers. Row headers should then read

    Treatment, Baseline
    Treatment, Contraceptive, 2 weeks
    Treatment, Contraceptive, 12 weeks
    Treatment, Contraceptive, 20 weeks
    Treatment, Recovery phase

and column headers should read

    Hormones, FSH [IU/L]
    Hormones, LH [IU/L]
    Hormones, Testosterone [nmol/L]

Arguably, when there is single top-level header group in some axis (the "evil (0,0) cell"), it might be better used as table caption (here probably something like "Treatment - Hormones [dosage]") and then omitted in header cells.

(From (HTML) accessibility perspective, all tables should better have caption element describing them.)

It does violate the perfect "Cartesian coordinates" normalization I described earlier, however I consider this is a permissible step up over the full normalization, because, while cutting down repetition (entirely), it still suggests a zero-ambiguity way to read off the values from the header cells.

Why not the Excel column / row notation?

On a side note, it is so irritating that chess notation is different than Excel notation.

Reply on news.ycombinator.com