Table cell widths (sometimes) being ignored about weasyprint HOT 10 CLOSED

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

from weasyprint.

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.

from weasyprint.

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.

from weasyprint.

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.

from weasyprint.

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.

from weasyprint.

AFAIK

Quelle mauvaise foi :)

from weasyprint.

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?

from weasyprint.

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.

from weasyprint.

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.

from weasyprint.

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:.

from weasyprint.