Description
https://drafts.csswg.org/css-align/#distribution-block
The block axis. If a is specified its fallback alignment is used instead. If no is specified, and the block container is not a scroll container, then alignment is safe.
For table cells, the behavior of align-content: normal depends on the computed value of vertical-align: top makes it behave as start and bottom makes it behave as end; otherwise middle makes it behave as center, and all other values make it behave as baseline.
My understanding is that vertical-align: bottom should behave as align-content: end, which behaves as align-content: safe end if the cell isn't a scroll container.
<!DOCTYPE html>
<style>
table { margin: 80px 0px }
td { height: 50px; }
td::before { content: ""; display: block; height: 250%; width: 50px; background: linear-gradient(to bottom, cyan, magenta) }
</style>
<table border="1">
<td style="overflow: visible; align-content: end"></td>
<td style="overflow: visible; align-content: safe end"></td>
<td style="overflow: visible; align-content: unsafe end"></td>
<td style="overflow: visible; vertical-align: bottom"></td>
</table>
<table border="1">
<td style="overflow: hidden; align-content: end"></td>
<td style="overflow: hidden; align-content: safe end"></td>
<td style="overflow: hidden; align-content: unsafe end"></td>
<td style="overflow: hidden; vertical-align: bottom"></td>
</table>| Blink | WebKit | Gecko |
|---|---|---|
 |
 |
 |
So Blink seems wrong because it treats vertical-align: bottom as align-content: unsafe end even if it's not a scroll container. But is it even web compatible to change the legacy behavior of vertical-align? If it's a scroll container, it's not following https://drafts.csswg.org/css-align/#auto-safety-scroll either.
WebKit seems wrong since it ignores the overflow position.
Gecko avoids overflow in this case so not conclusive.