-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-align-3][css-tables] vertical-align in orthogonal table cells #4033
Comments
I should test in browsers just to be sure, but as far as I know, My understanding is that the thing that is special about tables is not how vertical-align works, it is that after the alignment, all cells are stretched to the full line height, where in a block>inline situation, there is empty space above/below the aligned inlines.
I guess I should clarify that |
Working from the row rather than the cell seems confusing to me, but maybe, that just shows I don't understand how rows and cells and vertical-align works :) If it is working from the row's writing mode, what does it do if a cell has it's writing-mode orthogonal to the row? Say, a
|
Vertical-align works the same way for table cells in a table row as if you took all the cells of the row,
Here is an example: The only difference is that with table rows, you add padding to the cells so that their top and bottom sides meet the full row height (without shifting their content box) while for a normal flow line, you just leave blank space on either side of the line block. If you have boxes without background and border, are nothing positioned relatively to them, there is no difference between a table-cell row and an inline-block flow regarding how vertical-align works. Otherwise, the added padding has some impact. Here is the same example but with support for proper background/border/etc (addition of padding-top/padding-bottom to meet the row height after alignment, assuming things have roughly the same height as on my machine): https://jsfiddle.net/3jp2nwoy/1/ Now, you are correct that there is no way to visually center the content of an inline-block or block in its block axis if that block axis does not happen to match the parent one. That's a limitation of flows in general, not of table cells (which are more or less a block). My impression is that what you are trying to achieve is to add a That would be an issue against another spec however. The internal layout of a table-cell is just the layout of a block, so you would want to modify css-align to interact with blocks. cc @fantasai since she's the expert wrt css-align |
I should add to the previous explanation that if some cells have height, or if the row has an height, or if there are spanning cells forcing some rows to grow, things are still a bit different wrt a flow of inline-block in the sense that there is this additional constraints that may apply. If we had to think in terms of flow, I think the impact is roughly the same as if every line started with an anonymous inline-block of width 0px and of height being the height of the imposed height, with a vertical-align of top (because cells will lower their bottom to accommodate that constraint, if I recall correctly) Hopefully this comparison of |
This is currently defined in https://www.w3.org/TR/css-align-3/#distribution-block |
The CSS Working Group just discussed
The full IRC log of that discussion<TabAtkins> Topic: vertical-align on orthogonal table cells<astearns> github: https://github.com//issues/4033 <TabAtkins> florian: If we have a table-cell which is orthogonal to the table, and you verticla-align it, what does that mean? <TabAtkins> florian: "vertical" isn't a great word in the first place, but is it "vertical" in the table, or in the cell? <TabAtkins> florian: Related, how does that interact with the justify/align properties that are also trying to shift the table cell contents? <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. <TabAtkins> fantasai: vertical-align is like the *-content properties <TabAtkins> fantasai: When we drafted up the Align spec, we said that "align-content: normal" looks up vertical-align and does what it says. <TabAtkins> fantasai: (for table cells) <TabAtkins> fantasai: That works as expected for non-orthogonal cells. But for orthogonal ones, which writing mode is it using? <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. <TabAtkins> fantasai: So we could say that vertical-align doesn't apply to orthogonal cells. <TabAtkins> fantasai: Second is vertical-align applies when align-content is "normal" in the appropraite (table's) axis <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. <TabAtkins> fremy: Third was the behavior of EdgeHTML. <TabAtkins> fremy: vertical-align worked the same whether you had table cells or inline blocks. <TabAtkins> fremy: In both cases it cared about the line's direction, not the items. <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. <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. <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. <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. <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. <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. <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. <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. <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? <TabAtkins> fremy: I think so, yes, for any orthogonal cell. <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. <TabAtkins> dbaron: I think that's not *great*. <TabAtkins> florian: v-a and t-a are already parallel for orthogonal inline-blocks <TabAtkins> dbaron: They're a bit different because table-cells have a special behavior for vertical-align. <TabAtkins> fremy: Using the *-content properties you get full control. The old properties didn't always give you full control anyway. <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. <TabAtkins> fantasai: In text-align, you rely on the fact that the linebox fills the table cell. <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. <TabAtkins> fantasai: So basically orthogonal cells won't be affected by vertical-aign at all, since the linebox will fill the full height. <TabAtkins> TabAtkins: Yeah, I think that's what we expect actually. <TabAtkins> florian: Another possible model is that the vertical-align applies first, then you vertical-align the tight bounding box of the text. <TabAtkins> dbaron: Too many fundamental model changes for an edge case. <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. <TabAtkins> (parallel directions) <TabAtkins> TabAtkins: So what happens today? <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. <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` <TabAtkins> dbaron: So my preferred suggestion is that both v-a and t-a work on the cell's writing mode. <TabAtkins> fremy: Either case is potentially weird. I think it's weird to not follow the same model as inline-block. <TabAtkins> fremy: Maybe come up with a lot of examples and see what looks most reasonable? <TabAtkins> florian: I think from an author point of view what dbaron proposed makes more sense. <TabAtkins> florian: You've still got the two properties, they jsut rotate <TabAtkins> fremy: Still a difference - you'd have to redo row layout here, where in the "just stretch it" model you don't. <TabAtkins> dbaron: You need to redo layout once you discover the final row height anyway, for %s. <TabAtkins> florian: Every time I've used orthogonal table cells I've tripped over this, and wanted dbaron's behavior. <TabAtkins> fremy: So if I do make that change, would anyone want to implement it? <TabAtkins> dbaron: Which change? <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. <TabAtkins> dbaron: You do a second pass, and it can only increase the height. <TabAtkins> fremy: yes <TabAtkins> dbaron: In principle this seems reasonable, we have a bunch orthogonal cell bugs that haven't been a priority. <TabAtkins> TabAtkins: I can volunteer Aleks to look at this, yeah <TabAtkins> fantasai: the inline axis of an ortho cell is sized *after* the baseline alignment of the non-ortho cells in that row. <fantasai> RESOLVED: vertical-align operates in the block-axis of the table cell <fantasai> RESOLVED: the inline axis of an orthogonal table cell is sized *after* the baseline alignment of the non-orthogonal cells in that row |
Need clarification for implementation:
What happens when all cells are orthogonal? Is row height defined by minimum or maximum inline size? What are %ge inline/block sizes resolved against?
vertical-align: baseline is interesting. There is no "row baseline", what does baseline alignment means here? |
Good question. I would assume the minimum height.
During the first pass, auto? Does that make sense to you?
I would assume it's simply being ignored in this case. |
On an orthogonal cell, it means the cell doesn't participate in baseline alignment across cells in the same row, but it could participate in alignment across cells in the same column. I don't know how awful that would be implementation-wise given the state of table algorithms, but it's how things are defined for grids IIRC. :) |
I think that column baseline alignment for tables should not be supported unless someone demonstrates clear need for it. Implementing it is non-trivial, and has a corner case that cannot be implemented: descendants with percentage block sizes. Baseline computation for rows algorithm:
|
Agree,
Agree. |
Great, I'll be adding this into the spec, then. |
vertical-align
on things other than table cells behaves differently than on table cells. I am only talking about table cells here.Does "vertical" actually mean vertical, or does it mean block axis? if it means block axis, is that based on the writing mode of the table, or of the table cell?
I think it should be the block axis of the table cell (otherwise there is no way adjust alignment of the table cell content in that direction), but as far as I can tell, there's no spec that says that.
The text was updated successfully, but these errors were encountered: