Formatting tables best practices

[jonesyb]

I have had varying degrees of success formatting tables for eBooks. Here is an example of one I did recently that seems to work OK.

table { 
        max-width: 90%;
        border-collapse: collapse;
        border-spacing: 0;
        margin: 1em auto 0 auto;
        vertical-align: baseline;
    }
#table  td, th {
        border: 1px solid #ddd;
        padding: 5px;
    }

<table summary="" id="table">
    <tbody>
        <tr>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
        </tr>
        <tr>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
        </tr>
        <tr>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
        </tr>
        <tr>
            <td>
               ***
            </td>
            <td>
                ***
            </td>
            <td>
                ***
            </td>
        </tr>
    </tbody>

What is your method? Can you offer any improvements to what I have here? I would love to hear your insights as I want to make sure I am building them in the best way possible so they can be viewed properly on as many devices as possible.

[Turtle91]

That's almost exactly what I use. Although, I tighten up the css a little, but that is just technique, not at all required.

table { 
        max-width: 95%;
        border-collapse: collapse;
        margin: 1em auto;
    }
tbody  td {
        border: 1px solid black;
        padding: 5px;
        text-align:center
    }
tbody  td:first-child {
        text-align: right
    }

I usually format headers and footers differently than the body, so I use the "tbody td", "thead th", and "tfoot td" individually.

I have seen css using "id" tags to define something specific...especially if it is used with js, but I haven't figured out if there is a point to it just to say that it is a tag... (especially since the IDs need to be unique). eg. <table id="table">

...same concept as people using classes (<p class="para">, <blockquote class="block">, etc.). Just define the base tag, then use a class or ID for a specific deviation from the default.

If there IS a reason, I would be interested in knowing.

You will also hear that tables should only be used when you absolutely MUST... and anything larger than 2-3 columns should be re-thought as it really messes up the display on smaller screen sizes; large tables usually do better as an image.

[jonesyb]

Originally Posted by Turtle91

That's almost exactly what I use. Although, I tighten up the css a little, but that is just technique, not at all required.

table { 
        max-width: 95%;
        border-collapse: collapse;
        margin: 1em auto;
    }
tbody  td {
        border: 1px solid black;
        padding: 5px;
        text-align:center
    }
tbody  td:first-child {
        text-align: right
    }

I usually format headers and footers differently than the body, so I use the "tbody td", "thead th", and "tfoot td" individually.

I have seen css using "id" tags to define something specific...especially if it is used with js, but I haven't figured out if there is a point to it just to say that it is a tag... (especially since the IDs need to be unique). eg. <table id="table">

...same concept as people using classes (<p class="para">, <blockquote class="block">, etc.). Just define the base tag, then use a class or ID for a specific deviation from the default.

If there IS a reason, I would be interested in knowing.

You will also hear that tables should only be used when you absolutely MUST... and anything larger than 2-3 columns should be re-thought as it really messes up the display on smaller screen sizes; large tables usually do better as an image.

Thanks this is great! Looks like my tables aren't too far off then which is good to know.

Yes I have already made some tables in to images before that definitely would not be possible in an eBook. I also try to avoid them where possible.

[Tex2002ans]

Originally Posted by jonesyb

What is your method? Can you offer any improvements to what I have here? I would love to hear your insights as I want to make sure I am building them in the best way possible so they can be viewed properly on as many devices as possible.

Use HTML tables (<table>, <tr>, <th>, <td>):

<table>
	<tr>
		<th>Name</th>
		<th>Age</th>
	</tr>
	<tr>
		<td>Tex</td>
		<td>999</td>
	</tr>
	<tr>
		<td>Example</td>
		<td>123</td>
	</tr>
</table>

Avoid images of tables.

Using HTML allows font + size + color to be changed, read by Text-to-Speech, etc. etc. (Everything that makes ebooks great.)

For more details, see my posts:

• 2019: "Tables: what is the best way to render them on ebooks?" (Post #12+)
• 2013: "Tables in an epub?"

If you want to go further, you can introduce a <thead> along with your <tbody> + add scope= to your rows/column headings:

<table>
<thead>
	<tr>
		<th scope="col">Name</th>
		<th scope="col">Age</th>
	</tr>
</thead>
<tbody>
	<tr>
		<td>Tex</td>
		<td>999</td>
	</tr>
	<tr>
		<td>Example</td>
		<td>123</td>
	</tr>
</tbody>
</table>

<thead> will allow headings to duplicate after page breaks + help Text-to-Speech.

See:

• MDN: "<table>: The Table element"
• WebAIM: "Creating Accessible Tables"

And if you want your tables properly designed (so many tables are AWFUL)...

This GIF sums it up nicely:

"How to make your tables less terrible"

Pretty much:

• Text = Left-aligned, Numbers = Right-aligned
• Make headings match alignment of data
• No vertical lines
• Use spacing to organize rows/columns

If you want more technical details on that, I highly recommend the absolutely fantastic book: "The Visual Display of Quantitative Information" by Edward Tufte.

[hobnail]

Also similar to mine. But I think that the nth-child and first-child stuff doesn't work on the kobo, but I can't remember for sure. currentColor should be safer than black or some hex value; it does the right thing when the user switches to dark/night mode (white text on a black background); this is true everywhere you want black, not just tables.

table {
    margin-left: auto;
    margin-right: auto;
    border-collapse: collapse;
    margin-top: 1em;
}

table caption {
    font-weight: bold;
    padding-bottom: 0.5em;
}

table.coltwonum td:nth-child(2) {
    text-align: right;
}

table.colsthreenum td:nth-child(3) {
    text-align: right;
}

table.colfournum td:nth-child(4) {
    text-align: right;
}

table.colfivenum td:nth-child(5) {
    text-align: right;
}

td {
    border: 1px solid currentColor;
    empty-cells: show;
    padding: 0.125em;
    text-align: left;
}

tr.final {
   border-top:  2px solid currentColor;
}

[Tex2002ans]

I see you used caption in your CSS. How have you found support for that across devices?

I still include my captions in a separate <div>/<p>:

</table>

<div class="caption">
<p class="caption">Figure 1.1. This is an example.</p>
</div>

 div.caption {
	margin-bottom: 1em;
}

p.caption {
	text-align: center;
	text-indent: 0;
}

[phillipgessert]

Originally Posted by Tex2002ans

If you want more technical details on that, I highly recommend the absolutely fantastic book: "The Visual Display of Quantitative Information" by Edward Tufte.

A great book that's far less dry than the title would suggest!

[hobnail]

Originally Posted by Tex2002ans

I see you used caption in your CSS. How have you found support for that across devices?

My vague memory is that it worked. I only tried it on the kobo and kindle. Tables aren't something I normally do; this was in a book by Mark Twain.

[Tex2002ans]

Originally Posted by phillipgessert

A great book that's far less dry than the title would suggest!

I was just watching this great video today:

"Why Road Barriers Stopped Killing Drivers"

And about halfway through the video, they flash a few tables showing off death/safety statistics:



Bleh!!! Ptoowey!

1. You see all that centered alignment?

It makes it impossible to skim your eyes down a column and COMPARE rows. (The entire purpose of using a table in the first place.)

If you right-align numbers, all:

• 100s line with 100s
• 10s with 10s
• 1s with 1s

2. All those $ signs in every row?

Get rid of those and move those into the column header.

3. You see all those vertical lines?

You think you need them, but they're useless.

4. You see all those horizontal lines between rows?

You think you need them, but they're useless.

Optional exceptions: 1 above/below the table + 1 between the header/data.

(This visually separates the table from the text itself.)

* * *

Here's 3 versions of the same table in various stages of cleanup (from worse->better):

Spoiler:

Version A (Alignment):

----------------------------------------------------------
Severity          |  Minimum  |      Mean  |    Maximum 
                  |  Cost ($) |  Cost ($)  |    Cost ($)
----------------------------------------------------------
Fatal             | 190,200   | 4,288,422  | 10,100,000
Disabling Injury  |  89,200   |   781,094  |  3,300,000
Evident Injury    |       0   |   174,335  |    955,500
Possible Injury   |       0   |    98,188  |    955,500
PDO               |       0   |    10,582  |     42,298
----------------------------------------------------------

Version B (Remove verticals):

----------------------------------------------------------
Severity           Minimum         Mean     Maximum 
                   Cost ($)    Cost ($)     Cost ($)
----------------------------------------------------------
Fatal              190,200    4,288,422   10,100,000
Disabling Injury    89,200      781,094    3,300,000
Evident Injury           0      174,335      955,500
Possible Injury          0       98,188      955,500
PDO                      0       10,582       42,298
----------------------------------------------------------

Version C (Remove horizontals):

Severity           Minimum         Mean      Maximum 
                   Cost ($)    Cost ($)      Cost ($)

Fatal              190,200    4,288,422   10,100,000
Disabling Injury    89,200      781,094    3,300,000
Evident Injury           0      174,335      955,500
Possible Injury          0       98,188      955,500
PDO                      0       10,582       42,298

And here's what an HTML recreation might look like:



Same exact data. Perfectly readable, perfectly understandable.

Tools you need? Alignment + spacing.

Bold is optional (although not even needed).

Originally Posted by hobnail

My vague memory is that it worked. I only tried it on the kobo and kindle.

Thanks for the info. Last I tried it (a few years ago), I was having trouble with moving <caption> to the top:

https://developer.mozilla.org/en-US/...S/caption-side

so I gave up and didn't look much further. (I remember it working on a few of the devices, but failing on many others.)

It may be okay for very simple tables... but the kinds of complicated tables I work on, I just wrote off the entire thing.

But I'd definitely be open for anyone else's testing/research on it. In all these years on MobileRead, I can't recall anyone ever really speaking about <caption>.

[Turtle91]

I totally agree with Tex...especially for a full html website. But, for an ePub, I still don't like the look of large tables (more than 2-3 columns) on small screens (think phones in portrait mode). You just get too squished, or columns run off the page, or font has to be too small to fit everything...

[Tex2002ans]

Originally Posted by Turtle91

I totally agree with Tex...especially for a full html website. But, for an ePub, I still don't like the look of large tables (more than 2-3 columns) on small screens (think phones in portrait mode).

Read those Tables threads. All pros/cons of HTML Tables vs. Images-of-Tables are discussed at length.

The HTML advantages of Accessibility + TTS + searchability + copy/pastability + following user settings... outweigh the pros of static images. (Wow, "it looks the same" as the print book + I can use the background as a flashlight! )

Originally Posted by Turtle91

You just get too squished, or columns run off the page, or font has to be too small to fit everything...

This is one of the few cons, but even this has been mitigated in the past few years with better readers.

Like Kindle now allows you to expand/scroll large tables (similar to zooming + panning/scanning large resolution images).

I believe Kobo has similar functionality too.

You also have rotatable devices, so some can be flipped to landscape temporarily if you stumble across a wide table.

* * *

And on wide tables...

Transposing/Verticalization, where you flip the X- + Y-axis, can also be used. For example:

6x3

Name    Color  Cool?  Number  Tabs  # Teas
Tex     Red    Very        1    15      30
Turtle  Gray   Meh         2    99       5

3x6

Name    Tex   Turtle
Color   Red   Gray
Cool?   Very  Meh
Number     1    2
Tabs      15   99
# Teas    30    5

You may want to do this in your ebooks if you get to ~4-5+ columns, depending on the data.

Me and Hitch also discussed that (I believe in those same linked threads).

Print books are also limited by vertical size of the page, hence more horizontal tables.

Ebooks have infinite verticality, but limited horizontal space (skinny cellphones + large fonts), hence vertical tables may be better.

[Turtle91]

Originally Posted by Tex2002ans

...
This is one of the few cons, but even this has been mitigated in the past few years with better readers.

Like Kindle now allows you to expand/scroll large tables (similar to zooming + panning/scanning large resolution images).

That is really good to hear! Gotta love new tech!!
Is that tech just on new devices or is it supported on the older hardware?

Originally Posted by Tex2002ans

Transposing/Verticalization, where you flip the X- + Y-axis, can also be used. For example:
...
Ebooks have infinite verticality, but limited horizontal space (skinny cellphones + large fonts), hence vertical tables may be better.

I usually use auto-scroll on my reader, Marvin, so I truly have unlimited vertical space. However, if you have 'paged' content, does the ePub spec support the "display: table-header-group" property to repeat the header across breaking pages??

[Tex2002ans]

Originally Posted by Turtle91

That is really good to hear! Gotta love new tech!!
Is that tech just on new devices or is it supported on the older hardware?

Not sure, I don't have an actual Kindle, but it does show up in Kindle Previewer.

I assume it's a KFX thing.

Maybe jhowell or someone who has a Kindle can give more information.

Originally Posted by Turtle91

However, if you have 'paged' content, does the ePub spec support the "display: table-header-group" property to repeat the header across breaking pages??

I don't know about that specific CSS...

But when I use <thead> it duplicates headings to the next page in Gitden Reader (Android) + PocketBook Reader (Android) + even in an EPUB->DOCX conversion using EPUBTools.

I haven't done extensive testing though. And at the worst case, it'll just split tables/cells as normal.

[jhowell]

Originally Posted by Tex2002ans

Not sure, I don't have an actual Kindle, but it does show up in Kindle Previewer.

I assume it's a KFX thing.

Maybe jhowell or someone who has a Kindle can give more information.

The table viewer is part of the KFX renderer. It is enabled during conversion to KFX only for tables that meet the criteria to be considered a "data table". (I haven't investigated exactly what those criteria are.)

When enabled the table is followed by an icon of a box with a diagonal two headed arrow indicating that the table can be expanded. Clicking that opens a screen containing just the table that can be panned and zoomed like an image to view it in more detail.

[Tex2002ans]

Thanks for the detailed info.