FriendsOfEpub/Blitz

Tables: Why is td padding-left only 10px?

ptmkenny opened this issue · 3 comments

ptmkenny commented

Here's the CSS for <td>

td {
  empty-cells: show;
  border-bottom: ((@border-width / @body-font-size) + 0em) @border-style @border-color; /* Current color = color of text (inverted in night mode) */
  @computed-padding: (((@body-font-size * @body-line-height) - (@border-width * 2)) / @body-font-size);
  padding: (@base-margin / 2) 10px ((@computed-padding / 2) + 0em) 0;
  text-align: left;
}

Most of it is computed, but the padding-right value is fixed at 10px. Why is this?

For example, take a look at this screenshot from Kindle Previewer of a two-column table. It's extremely cramped, and it's hard to tell where one column begins and another column ends.

cramped table

JayPanoz commented

That’s the value mapping to the former 2% on smaller screens – % was an issue as it relied on a Reading-System-specific relayout.

Note we don’t officially support KFX (so Kindle Previewer 3) and decided to stop @ KF8 (so up to Kindle Previewer 2.x) given I had to retro-engineer their conversion scripts every time they update, which was unsustainable.

JayPanoz commented

@ptmkenny Maybe try with pt instead of px to see if that improves this result.

I can recall they changed how DPI works in their fork of Webkit – with a comment saying that they don’t respect the W3C standard any longer – so pt units might fix this issue, in which case I could change the default unit.

ptmkenny commented

@JayPanoz Thanks for the suggestion; unfortunately, pt gave me the same result.

For my case, I set the padding-left to @body-font-size + 0px. For Japanese, this gives a clean one-character indent, but it's probably a good way to calculate padding for English.