Make autogenerated ToC use a list

[windymilla]

It currently uses a paragraph with <br> to break the lines.

It might be possible to include page numbers where the headings occur.
Unfortunately display:grid which could lay out the list in a grid format is defined in https://www.w3.org/TR/css-grid-1/ which is (at time of writing) Candidate Rec Draft (despite being first drafted in 2011 and "universally supported" by browsers).

So, the page number would probably just have to follow the chapter title, e.g.
The Stormy Night, 27

NTS: Could investigate whether PG/Ebookmaker might agree to accept it. First check it does what's needed, e.g. can you emulate a 3-column ToC using display:grid? What's the status of alignment options?

[tangledhelix]

Most people just use a table (as the name implies, it's a table). Is there anything preventing the auto-toc from being a table?

[srjfoo]

Most people just use a table (as the name implies, it's a table). Is there anything preventing the auto-toc from being a table?

I thought Laura Brady said it should be a list?

[windymilla]

For many years, there has been a debate over whether the ToC should be a list or a table. I think the point is that a list is easier to navigate for screen readers, and there's also an argument, that you wouldn't want to do things like look down a column of page numbers, or add them up to get a total/average, or other "table-style" operations. Essentially, although it's typically printed as a table in our books, it's really a list of hyperlinks to locations in the book. That's the argument I've seen.

The problem with lists historically, is that if you're trying to reproduce the printed ToC, you almost certainly do want columns. People have tried to use float to achieve this, but in the past I've seen that break, or look terrible, when rendered in wide/narrow/epub formats. As mentioned in the issue description above, there is a "new" display:grid option, which could be the best of both worlds - it's still a list of hyperlinks, but spans within it are aligned into columns. As mentioned above, it hasn't made through the glacial acceptance process over the last 15 years, but is widely supported.

I intend to do some experiments, and possibly ask for it to be made an exception in ebookmaker, similar to the exception made for specific uses of flexbox. One good thing is that if the rendering device doesn't understand the CSS (e.g. in epub2) you still get a sensible ToC, with entries, like "VII. Stormy Night 236", and clicking it would take you to chapter 7 as it does now using a table.

[windymilla]

Needs resolution of Ebookmaker issue #322 before being tackled.

[rtonsing]

Just an opinion, but if screen readers can't handle a simple, very common, "Ch. # | Chapter title | page #" table format, that is a programming failure. I don't see how using contorted list definitions makes anything better. Software should be changed to handle the real world,
not the reverse.

Not to mention, who is going to pay for the staff to update the tens of thousands of existing ebooks at PG?

Reminds me of the hacks we used to do to make things work in ADE, when it was just plain bad software.

[windymilla]

Just an opinion, but if screen readers can't handle a simple, very common, "Ch. # | Chapter title | page #" table format, that is a programming failure. I don't see how using contorted list definitions makes anything better. Software should be changed to handle the real world, not the reverse.

I don't think it's that screen readers can't handle reading out the contents of the table - they can. But my understanding is that the typical way a table is read out would be long-winded and not easy to navigate.

In fact I think one of the strongest arguments for leaving things as they are, and not switching to a list, is that a user of assistive technology would likely use the contents from the epub navigation document (the one ebookmaker creates and can normally be accessed from anywhere in the book. This is also the place where the list of page numbers would go, and possibly other navigation lists, like list of illos. If the user can navigate to chapter 1 using that ToC, which is "built in" when reading our books in an e-reader, then they don't need to use the original printed ToC for navigation purposes.

[windymilla]

See second Laura Brady session for more detail on how this should be marked up (using flex & list)