Weasyprint: Table cell widths (sometimes) being ignored

[Smylers]

Have a look at http://www.stripey.com/demo/weasyprint/table_cell_width.html in a web browser and its rendering in WeasyPrint (version 0.16): http://www.stripey.com/demo/weasyprint/table_cell_width.pdf

All the tables have width: 100%.

In the second table WeasyPrint ignores % widths (applied to both columns, just to make sure), using the default widths for the content. Browsers (I checked Firefox and Chromium) behave as expected.

In the third table WeasyPrint ignores an em width setting on the left column, again using the default. Browsers behave as expected here: resizing the window only changes the (unspecified) width of the right column.

The fourth table shows the only way I've found of making WeasyPrint take note of cell widths: specifying an em width on each column. Despite the use of em, these are effectively proportional widths (obviously it isn't possible to use those specified widths while also having the entire table width add up to the required 100% of the page width). WeasyPrint matches browsers here: 10em out of a total of (10em + 15em) gives 40% to the first column and 60% to the second; browsers render this the same as the second table, with those % widths specified.

So it seems that percentage widths are ignored entirely, and other units' widths only have any effect if they're specified for every column; I'm not sure if that's two independent bugs or just one — let me know if you want me to split this into two separate issues.

[jamma313]

Try adding "table-layout:fixed" on the table, it worked for me, at least for units in percentage, and a CSS table..

[Smylers]

Thanks. table-layout: fixed fixes the 40%:60% and 10em tables.

Strangely it makes the 10em:15em table no longer be in that ratio, but I think that is allowed by the spec. Since the table width is greater than 25em the surplus space has to be distributed between the columns, and the spec is silent on whether that should be equally or in proportion to their existing widths (or something else).

I'm leaving this bug report open though, because I think at least some of the behaviour without table-layout: fixed is wrong. As a minimum, in the 40%:60% table the minimum width of the second column should be set to 60%, yet it clearly isn't being.

[SimonSapin]

Thanks for sharing your findings.

Percentages widths on table cells are ignored when the table has table-layout: auto (the default.) This is a known bug, or missing feature depending on your point of view. I haven’t yet looked at the rest of the issue.

[Smylers]

I think that's the only objective missing feature here.

There are other situations where WeasyPrint doesn't match browsers but the CSS spec doesn't insist on particular layout, so I think WeasyPrint's behaviour is allowed.

[liZe]

It should be fixed in 5b4b67e, feel free to test strange cases.

In the specification you can find that "If the table has 'width: auto', a percentage represents a constraint on the column's width, which a UA should try to satisfy." AFAIK, "should try to satisfy" means "do nothing" :).

Last missing feature: percentages are not handled on column groups.

[SimonSapin]

AFAIK

Quelle mauvaise foi :)

[liZe]

And fd5cbad handles percentages for column groups.

If you tell a child: "you should try to make your bed", he obviously understands "do nothing". And AFAIK, children are like kittens: they are always right.

Should we try to close this bug?

[Smylers]

As the original reporter, I'm closing this: re-running WeasyPrint 0.21 on the original demo file above now follows the 40%:60% constraints.

The 10em case still doesn't match browsers, but I think it does follow specs. And from a practical point of view, the desired behaviour for that case can be achieved with table-layout: fixed, so all layouts can now be achieved with WeasyPrint.

Thanks for fixing.

[SimonSapin]

The 10em case still doesn't match browsers, but I think it does follow specs.

Which spec is that? Note that the automatic table layout algorithm in CSS 2 is non-normative and does not match what browsers do.

http://dbaron.org/css/intrinsic/ is closer, although not a spec and slightly out of date according to the author.

[Smylers]

Sorry, that was sloppy phrasing on my part. By “follow specs”, I meant “behave in a way which is compatible with what specs actually require”.

That includes that non-normative CSS2 algorithm, which effectively treats width: on a table cell as being min-width:.