[css2] Percentages used to compute to auto; now compute to a percentage but are used as auto

[FremyCompany]

It seems the group accepted an errata in 2013 regarding the computed value of the "height" property. I think that was a mistake and would like to revert that errata. It was applied in those two commits.

This change requires to complexify all other specs in order to deal with the case of "broken percentages" everywhere we want to deal with the "auto" case. Since most specs didn't this is bound to continue to cause issues when developers reimplement specs or part of specs, like what happened in this Chrome issue.

Other specs continue to assume the old behavior, like css-sizing (in multiple places). Furthermore, it specifies this behavior for other values like fill-content etc when they can't resolve, like we do for percentages.

Note that percentages resolved against the intrinsic sizes (max-content, min-content, fit-content) will compute to auto, as defined by CSS 2.1.

[...] if the computed inline-size of the block is fit-content, auto, or stretch, its min-content inline-size contribution is its min-content inline size plus any inline-axis margin, border, and padding.

It is appropriate to resolve percentage heights on direct children of table cells if the cell is considered to have its height specified explicitly or the element is absolutely positioned, see CSS 2. It is further clarified that a cell is considered to have its height specified explicitly if the computed height of the cell [...] is a length or percentage.

cc @tabatkins @fantasai @dbaron @SimonSapin @bert-github

[FremyCompany]

We resolved in today's call to add some text in css-sizing to emcompass the notion of "height behaving as auto" that other specs can use and link to, so it is extra clear that ignored percentages are in fact considered in those cases where we currently incorrectly wrote "compute to auto".

We also need to edit at least css-sizing and css-text to refer to that concept (and maybe css 2?)

[mwenge]

Hi there, I'm not clear on the outcome here. Have y'all agreed to revert the erratum?

[FremyCompany]

No the errata will stay, but we agreed the other specs needs to be updated so they take the errata in consideration. This was just forgotten when the errata was made, but the errata didn't intend to change the meaning of those specs.

Btw the errata seems supported in all browsers as this test shows:
https://jsfiddle.net/nLxyer2c/

This was the only expected effect of the errata. Anything else is probably a spec that needs to be updated.