Re: [csswg-drafts] [css-tables] Calc for table layout (#94)

The CSS Working Group just discussed `Calc for table layout`, and agreed to the following:

* `RESOLVED: Any math expression of a complex type is treated as auto.  Simple typed things continue to work as today.`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic: Calc for table layout<br>
&lt;emilio> Github: https://github.com/w3c/csswg-drafts/issues/94<br>
&lt;emilio> xiaochengh: So the issue is what to do with percentages and calc<br>
&lt;emilio> ... spec says a bunch of stuff may be treated as auto<br>
&lt;fremy> "Given the complexities of width and height calculations on table cells and table elements, math expressions involving percentages for widths and heights on table columns, table column groups, table rows, table row groups, and table cells in both auto and fixed layout tables MAY be treated as if auto had been specified."<br>
&lt;emilio> ... I'm proposing changing the MAY into MUST<br>
&lt;emilio> ... it's pretty complicated if we don't treat it as auto<br>
&lt;fremy> q+<br>
&lt;emilio> ... second reason is that this is creating friction when implementing min() / max()<br>
&lt;emilio> ... calc() is complicated, but min() / max() make it a pretty hardly solvable problem<br>
&lt;emilio> ... so I propose to make this a MUST<br>
&lt;emilio> TabAtkins: this is what dbaron proposed back in the day<br>
&lt;emilio> ... and we punted min and max because of that<br>
&lt;emilio> heycam: implementation status?<br>
&lt;emilio> fremy: all browsers match the spec<br>
&lt;emilio> ... for normal table layout<br>
&lt;emilio> ... the algorithm just doesn't make it possible<br>
&lt;emilio> ... in fixed table layout there's one browser that supports percentages based on the size of the table<br>
&lt;emilio> ... as to the question of whether we should remove the behavior for normal table layout is fine<br>
&lt;emilio> ... for fixed layout it'd be nice to also remove it, but Chrome and Safari<br>
&lt;emilio> ... do respect it so it'd be nice to remove that<br>
&lt;emilio> ... or add to the spec that it is respected in fixed table layout and how, which should be straight-forward<br>
&lt;heycam> emilio: there's also the question of whether we should in presence of min and max ...<br>
&lt;heycam> ... Firefox uesd to treat calc(%) as auto<br>
&lt;heycam> ... we no longer do that<br>
&lt;heycam> ... but it raises the question of how min and max behave with only percentages<br>
&lt;heycam> ... I guess that's fine to resolve?<br>
&lt;heycam> TabAtkins: I don't want to special case min and max on type<br>
&lt;heycam> ... that's awkward<br>
&lt;heycam> ... having min and max work in some case if you have certain shapes of expression inside of it<br>
&lt;heycam> emilio: I think given the way we behave, all browsers treat calc with percentages as a percentage, we should do the same for min and max<br>
&lt;heycam> fremy: that sounds reasonable to me<br>
&lt;heycam> .... if there is a sum of % and px, after you've computed, then you decide not to do anything, follow the MUST<br>
&lt;heycam> ... if you have min(10%, 20%), the computed value will be 10%, so you don't have the problem<br>
&lt;heycam> .... I would be in favour of that wording<br>
&lt;heycam> emilio: what about calc(10% + 0)?<br>
&lt;heycam> ... that's simplifies to 10% in all browsers<br>
&lt;heycam> Rossen: yes we've resolved that previously<br>
&lt;heycam> fremy: so what about fixed mode<br>
&lt;heycam> ... I assume it's probably fine to apply this rule to both?<br>
&lt;heycam> RESOLVED: Any math expression of a complex type is treated as auto.  Simple typed things continue to work as today.<br>
&lt;emilio> TabAtkins: https://github.com/w3c/csswg-drafts/issues/3482#issuecomment-451590359<br>
&lt;heycam> zoe: no objections<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/94#issuecomment-532128184 using your GitHub account

Received on Tuesday, 17 September 2019 08:55:30 UTC