Tables should look good, and like tables, by default

[eallenOP]

From: https://wiki.csswg.org/ideas/mistakes

For example, who ever wanted non-collapsed borders (or no borders) by default? Not sure if borders count as layout though...

Padding? Tables without padding are not readable.

[jensimmons]

This sounds good. Do you have some suggestions for code to add to Remedy? (You can write it here so we can discuss, no need to be sure / make a pull request.)

[tylersticka]

I took a look through our last several design system projects, and found a surprising amount of variation (to me, anyway) between table styles when it came to properties like padding, border-spacing and even width (I really thought we'd be applying width: 100%, but I found two projects where we are not).

These styles were the only ones that we seemed to consistently apply as defaults:

/**
 * 1. Prevent double borders
 * 2. Without this, th elements won't inherit their alignment predictably in
 *    Safari. Setting alignment here makes it easier to override on the
 *    containing element (if desired).
 */

table {
  border-collapse: collapse; /* 1 */
  text-align: left; /* 2 */
}

/**
 * Make th alignment consistent with td alignment
 */

th {
  text-align: inherit;
}

This doesn't address the proposed padding readability issue, and our techniques, customers and end users may differ from others, but I thought I'd provide as a point of discussion and consideration. 🙂

[eallenOP]

How opinionated should this be? For example, is a table more table-ish when it has borders than when it doesn't? Is there any use at all in a table where every bit of content is squished right up against its neighbours? If we do want padding, how would we decide how much?

In which case do we add something like:

th, td {
  border: 1px solid black;
  padding: 5px;
}

or is this way too opinionated (and everyone will set their own table styles anyway)?

[hacknug]

The amount of padding should/could be consistent with the spacing scale used for headings and paragraphs.

[tylersticka]

or is this way too opinionated (and everyone will set their own table styles anyway)?

I hope others will chime in (as I wouldn't want direction to be informed by my team's experience alone), but border and padding styles are among the first things that we seem to customize per project (and not consistently so). My instinct would be to leave them out.

(If I'm wrong about that, I'd consider using currentColor instead of black for the border?)

[scottkellum]

I like it! I’d maybe amend it to be like this

th, td {
  border: 1px solid;
  padding: 0.5rem;
}

currentColor is the default for border so there is no need to write it. Also padding in rem allows it to fit better with the chosen base font size so it can scale up and down based on foundational design decisions of that project.

[meyerweb]

Perhaps the padding should be rem-based in the inline direction, and em-based in the block direction, something like padding: 0.2em 0.5rem 0.1em. Although this is starting to get pretty opinionated.

[eallenOP]

There are kinda opinionated things that we all override already in CSS though, I guess. Otherwise everything would be as jammed together as tables are by default. Line height is an example - you've got to have some kind of line height by default (as discussed in #7 ). Also, how did it get decided how much margin to put on paragraphs by default (#1 )? I think table padding falls into this category too, and since we're moving away from everything being specified in exact pixels then yeah, rems and ems FTW.

So far we are up to

table {
  border-collapse: collapse;
  text-align: left;
}

th {
  text-align: inherit;
}

th, td {
  border: 1px solid;
  padding: 0.2em 0.5rem 0.1em;
}

This works in my world. Other perspectives?

[tylersticka]

The only part of that code that feels too opinionated to me is the mismatched vertical padding. I'd simplify to something like 0.2em 0.5rem.

Just my two cents, though! 🙂

[meyerweb]

The mismatching helps vertically balance the text in the cell, because it compensates for the (roughly) tenth of an em below the baseline of the text, where there’s a lot of open space that’s not counted in vertical padding.

[tylersticka]

That makes a lot of sense for text. A lot of our customers use tables primarily for laying out specification data, and since that's often numeric, I find mismatched vertical padding less beneficial?

Mismatched Example

Consistent Example

(There are certainly other improvements to be made in these examples... text alignment, for instance... but wanted to provide a "for instance" rather quickly.)

On a scale of 1 to 10, my passion level on this is maybe a 3 or 4, so it's all good if we agree to disagree. 🙂

[scottkellum]

It might be worth adding font-variant-numeric: tabular-nums; to the table CSS to ensure the numbers line up.

[jensimmons]

Researching for something else entirely, I just ran across this excellent run-down on styling tables: https://css-tricks.com/complete-guide-table-element/

[Malvoz]

From: https://wiki.csswg.org/ideas/mistakes

For example, who ever wanted non-collapsed borders (or no borders) by default?

Turns out border-collapse: collapse disables position: sticky (presumably for <thead> and <tr> elements), reference: https://bugs.chromium.org/p/chromium/issues/detail?id=702927#c35.

Additionally, overflow: hidden on <table> also disables stickyness, overflow: clip on the other hand might enable the intended behavior of hiding overflow and keeping stickyness, reference: https://github.com/w3c/csswg-drafts/issues/865#issuecomment-621280699.

Not sure what to do with this information - perhaps it is out of scope - to include it as a CSS comment on sticky positioning in regards to tables?