Table column widths

[slochower]

trafficstars

I'll start by saying I'm not certain how Markdown tables get styled by our CSS theme. I'm seeing different columns widths in HTML and PDF (generated by Athena).

(Ignore the page break & also ignore the absolute width of the table; I just attempted to zoom the PDF to approximately the same size as the HTML version. I'm talking about column widths for now.)

• I think it would be nice to understand why this is happening, specifically, why the "SMILES" column seems to take up proportionally more of the total column width in HTML compared to PDF. I didn't see anything obvious in our default.html styling.

• But more generally, it would be nice to have control over column layout. I think the changes in #251 can help with that, aside from the explicit examples therein. It would be nice to have columns "auto fit" the content, so a column with single digits will be smaller than one with longer text. It might also be useful to have another column, like "SMILES", grow as big as possible without wrapping the other columns. I don't know how difficult these changes would be, but I think it's worth discussing.

CC @vincerubinetti

[vincerubinetti]

I think it would be nice to understand why this is happening

First, I should say that tables are one of the most difficult things in the HTML spec, even for someone like me who's used them for years.

See these links for some background information: https://developer.mozilla.org/en-US/docs/Web/CSS/table-layout https://developer.mozilla.org/en-US/docs/Web/HTML/Element/colgroup

By default, most browsers use an automatic table layout algorithm. The widths of the table and its cells are adjusted to fit the content.

We don't actually style tables at all, in terms of setting widths. However, it looks like pandoc automatically adds a <colgroup> tag to every table, with each column being an equal width. My guess is that Chrome just ignores this (as I believe it's not the expected way to set column widths anymore), but Athena honors it. In your Athena screenshot, the columns appear to be about equal width.

To solve this, ideally we'd have pandoc not put those colgroups in there at all, so we can leave it to the browser to auto fit, or so we can override at will.

From some cursory experimentation, as long as that <colgroup> is there, the only way to mess with the column widths is to set eg min-width: 100px in the topmost row. @slochower for example:

I don't know if that will work in Athena though. If it does, though, then yes, the new plugin should be able to do this.

[slochower]

Thanks for your perspective and highlighting some of the difficulties.

I tried <!-- min-width: 200px --> and <!-- element.style="min-width: 200px" --> in the first row, with your attributes.html, but neither took effect. But then I also tried the colspan example in #251 and I couldn't get that to take effect either, so perhaps attributes.html is not working as expected in my case. I'll try to circle back to what happens with Athena when I can get it looking right in the HTML.

Here in Firefox with version 352009b of attributes.html and adding

[...]
  --include-after-body=build/plugins/lightbox.html \
  --include-after-body=build/plugins/attributes.html \
  --mathjax \
[...]

to build.sh.

[vincerubinetti]

<!-- element.style="min-width: 200px" -->

It wouldn't be element.style, it would just be style. As the plugin's currently (in the hash you linked) written, you need to have it exactly like this:

<!-- attribute="value" -->, or in your case: <!-- style="min-width: 200px" -->. No preceding # or any kind of CSS selectors. Otherwise, it would read the attribute as #colspan, and there is no such attribute in HTML. It's colspan.

[slochower]

Nice! Some tuning is necessary (because our HTML view is pretty narrow), but this is a big improvement.

PDF via Athena:

HTML:

[dhimmel]

I think Pandoc may have some ability to specify relative column widths as per the docs:

The cells of pipe tables cannot contain block elements like paragraphs and lists, and cannot span multiple lines. If a pipe table contains a row whose printable content is wider than the column width (see --columns), then the table will take up the full text width and the cell contents will wrap, with the relative cell widths determined by the number of dashes in the line separating the table header from the table body. (For example ---|- would make the first column 3/4 and the second column 1/4 of the full text width.) On the other hand, if no lines are wider than column width, then cell contents will not be wrapped, and the cells will be sized to their contents.

I think I've had some success with this approach in the past, but not a ton. The HTML attribute plugin which we should hopefully release soon in https://github.com/manubot/rootstock/pull/251 seems like the best fallback.

If so, perhaps we can close this issue?

[slochower]

Yes, but perhaps also worthwhile to add an example in the docs.

On Mon, Sep 9, 2019 at 9:19 AM Daniel Himmelstein [email protected] wrote:

I think Pandoc may have some ability to specify relative column widths as per the docs https://pandoc.org/MANUAL.html#extension-pipe_tables:

The cells of pipe tables cannot contain block elements like paragraphs and lists, and cannot span multiple lines. If a pipe table contains a row whose printable content is wider than the column width (see --columns https://pandoc.org/MANUAL.html#option--columns), then the table will take up the full text width and the cell contents will wrap, with the relative cell widths determined by the number of dashes in the line separating the table header from the table body. (For example ---|- would make the first column 3/4 and the second column 1/4 of the full text width.) On the other hand, if no lines are wider than column width, then cell contents will not be wrapped, and the cells will be sized to their contents.

I think I've had some success with this approach in the past, but not a ton. The HTML attribute plugin which we should hopefully release soon in #251 https://github.com/manubot/rootstock/pull/251 seems like the best fallback.

If so, perhaps we can close this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/manubot/rootstock/issues/254?email_source=notifications&email_token=ABJE4S7ZFVK7X7W322I4AQTQI2OU5A5CNFSM4IFLLFTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6IXM7Y#issuecomment-529626751, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJE4S3LH5CMKUPVHLPAUTLQI2OU5ANCNFSM4IFLLFTA .

[vincerubinetti]

Revisiting this issue over a year later, I have some new thoughts.

First, I should've asked to see what the pandoc-generated <colgroup> looked like in his manuscript. At a high level, the difference in output between Chrome and Athena seems like an Athena issue. The Athena output looks like equal width cols, which should never be happening, so something is wrong there.

More generally, my thought is that this is a complex problem and we might need a general, robust, custom solution.

The pandoc "solution" of adding more dashes and generating <colgroup> seems to be ineffective. It only gets applied to some tables, when the content has to wrap (we could change --column to 1 to make sure tables always have <colgroup>, but it seems like doing that would have side effects).

Also, <colgroup> (or unfortunately ANY method of specifying column width) needs the table to have a fixed width. This will screw up our CSS styling. We'd have to set table widths to always be 100% (full page width), and that would be no horizontal scrolling, and thus long words/strings would have to force-break/wrap, which could cause headaches for some users. However this would have the nice benefit of making the HTML and PDF view the same for table.

More thought is needed.

Related reading (mostly for me later): https://stackoverflow.com/questions/41913896/should-i-use-colgroup-and-col-and-if-so-why-and-how https://stackoverflow.com/questions/1238115/using-text-align-center-in-colgroup

[cmungall]

Is there any update on this?

I'm having some issues with tables being truncated and to be honest I'm having trouble trying to figure out how the apply any of the advice in this issue. I haven't used pandoc much beyond basic conversion, I am utterly clueless about CSS stylesheets.

I think it would be super-awesome if there were a small entry-level how-to guide on best practices for tables in the docs somewhere.

[vincerubinetti]

I will try to take a detailed look at this when I return from a conference next week.

For now you might enabling the attributes plugin and adding e.g. <!-- style="min-width: 200px" --> to each header cell to manually specify column widths.

Also screenshots here are very helpful. Are you encountering this in the html or pdf export? Is it getting cut off completely off the side, or is it otherwise incorrectly sized or text wrapped?

[vincerubinetti]

Okay, read through and thought about this once again. Here are some thoughts.

Firstly, having trouble getting Athena PDF to run on my work M1 MacBook. Also, I just noticed that Athena is now deprecated 😕:

This repository has been archived by the owner on Apr 25, 2023. It is now read-only.

Looking at our theme CSS, I think everything is how it needs to be right now. The table is set to be 100% width so it should never overflow the width of the page; it should create a scrollbar (if too wide) on screens, and squash to fit on print.

If someone, or we by default, wanted to have the tables not stretch to full width (to more often match the specified column widths), we could do the following themes/default.html css changes:

• for .tablenos, change width: 100%; to max-width: 100%;
• for table, change width: 100%; to max-width: 100%;
• for .tablenos > table, change margin: 0; to margin: 0 auto;

Keep in mind though, that without table-layout: fixed, any method we use to specify column widths is a suggestion. And I think that's the way we need to keep it, because the browser can dynamically and intelligently (most of the time) adjust the sizing of things based on the contents of the table. And when printing, overflow-wrap: break-word; is set on table contents so long strings should be able to wrap to the next line.

Now, back to specifying column widths.

What do others think about leaving in using the pandoc extra table markdown dashes to widen the columns? At the moment it actually seems fairly intuitive to me. But, it results in <colgroup>s, which are an older approach that seems to mess with tools like Weasy and Athena (I think Athena ignoring the colgroups and making everything equal width is definitely an Athena bug, in their court), and don't seem to play nice with any additional CSS rules you might want to apply for more flexibility.

I realized though that we should just be able to add a colgroup { display: none; } CSS rule to ignore them, rather than messing with pandoc options. Though I can't even run Athena to verify if this works in it.

If <colgroup> is able to be removed, we could just recommend using the attribute plugin to set the widths where needed, like:

| *Bowling Scores* <!-- $style="width: 100px" --> | Jane          | John          | Alice         | Bob           |
|:-----------------|:-------------:|:-------------:|:-------------:|:-------------:|
| Game 1 | 150 | 187 | 210 | 105 |
| Game 2 |  98 | 202 | 197 | 102 |
| Game 3 | 123 | 180 | 238 | 134 |

But this might not be needed nearly as often, as maybe the browser auto sizing the table based on contents would work well enough in most cases, as opposed to the more-rigid and harder to eyeball dashes.

If we leave it as dashes, we should put a comment in delete-me.md in rootstock explaining that the number of dashes affects column widths.

Side note, a cleanup item for me: the .tablenos table, .tablenos table * { overflow-wrap: normal !important; } should be redundant and removeable.