- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2020 16:54:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `vertical-align on orthogonal table cells`, and agreed to the following: * `RESOLVED: vertical-align operates in the block-axis of the table cell` * `RESOLVED: the inline axis of an orthogonal table cell is sized *after* the baseline alignment of the non-orthogonal cells in that row` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: vertical-align on orthogonal table cells<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4033<br> <TabAtkins> florian: If we have a table-cell which is orthogonal to the table, and you verticla-align it, what does that mean?<br> <TabAtkins> florian: "vertical" isn't a great word in the first place, but is it "vertical" in the table, or in the cell?<br> <TabAtkins> florian: Related, how does that interact with the justify/align properties that are also trying to shift the table cell contents?<br> <TabAtkins> fantasai: There are two types of properties here. *-self, which apply to the box itself in its context, and *-content, wich apply to the contents of the box relative to the box.<br> <TabAtkins> fantasai: vertical-align is like the *-content properties<br> <TabAtkins> fantasai: When we drafted up the Align spec, we said that "align-content: normal" looks up vertical-align and does what it says.<br> <TabAtkins> fantasai: (for table cells)<br> <TabAtkins> fantasai: That works as expected for non-orthogonal cells. But for orthogonal ones, which writing mode is it using?<br> <TabAtkins> fantasai: The *-content properties work in the container's writing mode (the table cell). But vertical-align probably applies in the table's writing mode.<br> <TabAtkins> fantasai: So we could say that vertical-align doesn't apply to orthogonal cells.<br> <TabAtkins> fantasai: Second is vertical-align applies when align-content is "normal" in the appropraite (table's) axis<br> <TabAtkins> fantasai: Third is that both align/justify-content is potentially affected by vertical-align: use the writing mode of the table to figure out which property on the table cell cares about vertical-align.<br> <TabAtkins> fremy: Third was the behavior of EdgeHTML.<br> <TabAtkins> fremy: vertical-align worked the same whether you had table cells or inline blocks.<br> <TabAtkins> fremy: In both cases it cared about the line's direction, not the items.<br> <TabAtkins> fremy: Complication with tables is just that, at the end, you have to alter the size of the cell to make them all the same height. But before that, the algorithm is identical to inline-blocks in a text line.<br> <TabAtkins> fremy: So based on that, I think it makes the most sense for v-a to work the same in both, applying in the axis of the line.<br> <TabAtkins> fremy: Downside is that you lose some control here; you can't necessarily apply the place-* keywords because vertical-align has already added magic padding to align things.<br> <TabAtkins> fremy: Possibility is that if you say "*-content: normal", you do the normal vertical-align stuff, but if you say any other keyword, vertical-align has no effect.<br> <TabAtkins> florian: Initially I thought this was counter-intuitive, as v-a on table-cells doesn't *seem* to do the same as alignment; because of the extra padding added, it felt like it wasn't shifting boxes, it was shifting the content of the box.<br> <TabAtkins> florian: So if that's your model, you might think that it should align in the cell's writing mode, rotated relative ot the table.<br> <TabAtkins> florian: So it's a little counter-intuitive to me, but v-a is anyway, and the underlying model is sensible. So as long as we get *-content to actually work on table cells, you can achieve whatever result you wanted.<br> <TabAtkins> florian: If v-a was the only property we could use, we might want something different, but as the spec stands it seems okay.<br> <TabAtkins> dbaron: A lot of legacy table stuff maps into verticla-align or text-align depending on writing-mode. Does this cause them to ever act on the same axis?<br> <TabAtkins> fremy: I think so, yes, for any orthogonal cell.<br> <TabAtkins> florian: I think it's a problem that previously you used text-align and vertical-align to control everything, and having them always be perpendicular was good, but now we have the *-content properties which definitely are perpendicular.<br> <TabAtkins> dbaron: I think that's not *great*.<br> <TabAtkins> florian: v-a and t-a are already parallel for orthogonal inline-blocks<br> <TabAtkins> dbaron: They're a bit different because table-cells have a special behavior for vertical-align.<br> <TabAtkins> fremy: Using the *-content properties you get full control. The old properties didn't always give you full control anyway.<br> <TabAtkins> fantasai: I think dbaron's issue is valid. The model of vertical-align requires that the content is smaller than the table cell and you add padding.<br> <TabAtkins> fantasai: In text-align, you rely on the fact that the linebox fills the table cell.<br> <TabAtkins> fantasai: verticla-align doesn't have stretch, it aligns you to some spot, and only applies if the item is smaller than the container.<br> <TabAtkins> fantasai: So basically orthogonal cells won't be affected by vertical-aign at all, since the linebox will fill the full height.<br> <TabAtkins> TabAtkins: Yeah, I think that's what we expect actually.<br> <TabAtkins> florian: Another possible model is that the vertical-align applies first, then you vertical-align the tight bounding box of the text.<br> <TabAtkins> dbaron: Too many fundamental model changes for an edge case.<br> <TabAtkins> florian: So we're saying that text-align applies in the only axis it can possibly make sense, and vertical-align applies in the table's writing mode.<br> <TabAtkins> (parallel directions)<br> <TabAtkins> TabAtkins: So what happens today?<br> <TabAtkins> fremy: Orthogonal cells don't work at all in Chrome or Safari, EdgeHTML used the behavior we're discussing, and Firefox has broken sizing behavior.<br> <AmeliaBR> If anyone else wants to look at current browser behavior, I made a test: https://codepen.io/AmeliaBR/pen/afcd79a788685ccee7892f733cc8251f Chromium currently ignores `writing-mode` on a `td`. Firefox supports them, though it's weird. It uses the table's definition of top/bottom for `vertical-align`<br> <TabAtkins> dbaron: So my preferred suggestion is that both v-a and t-a work on the cell's writing mode.<br> <TabAtkins> fremy: Either case is potentially weird. I think it's weird to not follow the same model as inline-block.<br> <TabAtkins> fremy: Maybe come up with a lot of examples and see what looks most reasonable?<br> <TabAtkins> florian: I think from an author point of view what dbaron proposed makes more sense.<br> <TabAtkins> florian: You've still got the two properties, they jsut rotate<br> <TabAtkins> fremy: Still a difference - you'd have to redo row layout here, where in the "just stretch it" model you don't.<br> <TabAtkins> dbaron: You need to redo layout once you discover the final row height anyway, for %s.<br> <TabAtkins> florian: Every time I've used orthogonal table cells I've tripped over this, and wanted dbaron's behavior.<br> <TabAtkins> fremy: So if I do make that change, would anyone want to implement it?<br> <TabAtkins> dbaron: Which change?<br> <TabAtkins> fremy: That v-a and t-a both work in the cell's w-m, so you have to do a second layout pass.<br> <TabAtkins> dbaron: You do a second pass, and it can only increase the height.<br> <TabAtkins> fremy: yes<br> <TabAtkins> dbaron: In principle this seems reasonable, we have a bunch orthogonal cell bugs that haven't been a priority.<br> <TabAtkins> TabAtkins: I can volunteer Aleks to look at this, yeah<br> <TabAtkins> fantasai: the inline axis of an ortho cell is sized *after* the baseline alignment of the non-ortho cells in that row.<br> <fantasai> RESOLVED: vertical-align operates in the block-axis of the table cell<br> <fantasai> RESOLVED: the inline axis of an orthogonal table cell is sized *after* the baseline alignment of the non-orthogonal cells in that row<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4033#issuecomment-577281286 using your GitHub account
Received on Wednesday, 22 January 2020 16:54:29 UTC