Re: [csswg-drafts] [css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box? (#11408)

The CSS Working Group just discussed `[css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> … first you layout the table without collapse, and then remove th ecollapsed tracks<br>
&lt;bramus> … this is about collapsing of rows and cols<br>
&lt;bramus> … typically it is ht eparent formatting context that decides th esize of a box, but here it is like the table and this can confus the parent FC<br>
&lt;bramus> … was investigating what browsers do<br>
&lt;bramus> … only checked gecko and blink<br>
&lt;oriol> https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2563995794<br>
&lt;iank_> q+<br>
&lt;bramus> … there is a table in this comment I linked to<br>
&lt;bramus> … some shrink or do not shrink<br>
&lt;bramus> … ?? they dont collapse which I think is right. would otherwise be bad if table is inside an inline-block<br>
&lt;bramus> … when actually deciding final size of the table ther eare diferences<br>
&lt;bramus> … gecko has wrapper table box and ?? box, and blink only has single box.<br>
&lt;bramus> … in the inline axis gecko does not shrink the table wrapper box, only the table grid box<br>
&lt;bramus> … this has nice properties lik avoiding conflicts with PFC<br>
&lt;bramus> … some slightlly surprinsg things like cnetering with auto margins it only cneters the wrapper so could be off center<br>
&lt;bramus> … blink has a single box and tries to shrink “both” things<br>
&lt;bramus> …but it does not shrink in a flex row bc it could conflict with flex sizing algo I think<br>
&lt;bramus> … what does it mean if the table is suddenly shrinking?<br>
&lt;bramus> … does not shrhink for tables that have flex items in a row or if the table is abspos<br>
&lt;bramus> … otherwise it behaves a if table wrapper shrinks<br>
&lt;bramus> … for table grid gecko ??? it shrinks except for flex rows and abspos boxes<br>
&lt;bramus> … things that are more itneresting in the block axis: both try to shrink as much as possible<br>
&lt;bramus> … but in flex columns no browsers shrinks the intrinsic block contributions<br>
&lt;bramus> … for final size of the tbl wrapper blocks gecko ???, blink doe snot shirnk the wrapper but doe shrink the grid<br>
&lt;bramus> … not sure whatis going on.<br>
&lt;bramus> … I like gecko’s inline-axis behavior<br>
&lt;bramus> … not sure about the block<br>
&lt;bramus> … like that a box can decide to if inline size conficts with PFC it can shrink<br>
&lt;bramus> … there are several things to discuss here<br>
&lt;Rossen3> ack iank_<br>
&lt;bramus> iank_: 1 thing I dislike is that when we set a height 100px on a table it will shrink both ??? seems like a ?? on the wrapper box side<br>
&lt;bramus> … if we end up with resolution that keeps the wrapper box at 100px tha twould b egood<br>
&lt;bramus> … some complexity … if all ?? size up to the inner grid box<br>
&lt;bramus> … not sure what to do there<br>
&lt;bramus> fantasai: for the margin case I wonder we could prolly compensate for that by either having the auto margins also do sth to the tabl egrid box or just saying authors should use the alignment properties to align both boxes<br>
&lt;fantasai> s/should/can/<br>
&lt;Rossen3> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to comment on alignment<br>
&lt;bramus> iank_: oriol, can you say why you don tlike affecting th eintrinsic contributions?<br>
&lt;oriol> https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2653101446<br>
&lt;bramus> oriol: see this link<br>
&lt;bramus> … if you have a table that is inside an inline-block and the table has 2 cols, one of which is collapsed, and each coll has a cell with min-content size of 50 and max content of 100<br>
&lt;bramus> … if you dont take collpased tracks into account the of the tbl is 200px<br>
&lt;bramus> … if we decided to change this, it could be 200 but removing 1 col, so 100px<br>
&lt;bramus> … problem is that when we lay out table for real, we only have 100px of avialbe space to give both cols<br>
&lt;bramus> … so each would be 50px instead of 100px<br>
&lt;bramus> … what will happen is that we end up with 1 col of 50px and its not the ideal size<br>
&lt;bramus> iank_: makes sense<br>
&lt;bramus> … making intrinsic block contributions match inline contributions would be the right way to go there for consistency<br>
&lt;bramus> … and we likely are not constrained too much bc webkit doe snot have this feature yeat<br>
&lt;bramus> … might need to think a bit more about the wrapper and grid box sizes<br>
&lt;bramus> … the way that they work could be funky<br>
&lt;bramus> Rossen3: Oriol, where do you want to take this?<br>
&lt;bramus> … the issue or try for a resolution?<br>
&lt;bramus> oriol: if Ian wants to think more about it, we can bring back to the issue<br>
&lt;bramus> … this even belongs to CSS2, so a bit weird that we have this<br>
&lt;bramus> … but can bring back to the issue<br>
&lt;bramus> iank_: if you (oriol) write down possible solutions, that would be helpful<br>
&lt;bramus> … what you think is the best<br>
&lt;bramus> … I can also propose something<br>
&lt;bramus> Rossen3: So let’s take it back to the issue<br>
&lt;bramus> … perhaps we can have a proposed resolution by the next time<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 26 February 2025 17:49:03 UTC