- From: Gérard Talbot <www-style@gtalbot.org>
- Date: Mon, 23 Mar 2015 19:20:59 -0400
- To: Robert Hogan <robhogan@gmail.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, W3C www-style mailing list <www-style@w3.org>
Le 2015-03-23 15:42, Robert Hogan a écrit :
> OK, so I'd like to propose the following as the behaviour to converge
> on.
>
> Case One:
>
> There is nothing in CSS 2.1 that forces the cell to be anything greater
> than 1px in this test. While the size of the row and the table may be
> up
> for grabs (as behaviour with percentage height is not defined) the cell
> has
> a specified height and has no reason to be higher than 1 px. It is the
> containing block for its content, so the content has no reason to
> exceed
> 1px either.
The height of table element, table-row and table-cell do not work like
the height of block containers. The table box (not the anonymous table
wrapper box) and table-row objects are not block containers. Overflow do
not apply to table box and table-row.
> Gerard, in connection with this test you mentioned: “In your test,
> because
> the table only has 1 row and 1 single cell, the single cell is
> constrained
> to honor the 100% height declaration on the table element, the cell
> height
> has to increase dramatically.” Why do you believe the cell is
> constrained
> to ignore its 1px height in this case?
>
> http://jsbin.com/wabileduma/1/edit?html,output
I'm sorry. This was more the result of a visual interpretation of what
was rendered in a few browsers than the result of a solid spec reading
and interpretation.
> <!DOCTYPE html>
>
> <html>
>
> <style>
>
> .content {
>
> background-color: green;
>
> }
>
> .table {
>
> display: table;
>
> }
>
> .row {
>
> display: table-row;
>
> }
>
> .cell {
>
> display: table-cell;
>
> height: 1px;
>
> }
>
> div, html, body {
>
> height: 100%;
>
> width: 100%;
>
> }
>
> </style>
>
> <body> <!-- Should be viewport height -->
>
> <div class="table"> <!-- Should be viewport height -->
>
> <div class="row"> <!-- Should be viewport height -->
>
> <div class="cell"> <!-- Should be 1px height -->
>
> <div class="content"> <!-- Should be 1px height -->
>
> </div>
>
> </div>
>
> </div>
>
> </div>
>
> </body>
>
> </html>
>
>
> Case Two:
>
> As with Case One the container in the cell respects the specific height
> of
> the cell.
>
> <!DOCTYPE html>
>
> <style>
>
> table {
>
> width: 250px;
>
> }
>
> td {
>
> width: 242px;
>
> }
>
> .cell-specified-height {
>
> height: 202px;
>
> }
>
> .container {
>
> height: 100%;
>
> overflow-y: hidden;
>
> }
>
> .content {
>
> background-color: black;
>
> height: 2000px;
>
> width: 225px;
>
> }
>
> </style>
>
> <table>
>
> <td class="cell-specified-height" data-expected-height=206>
Did you mean that the expected offsetHeight of cell is 206 ?
202px plus default 1px padding-left plus default 1px padding-right
should give 204px, no?
>
> <div class="container" data-expected-height=204>
Why expected height is not 202 ?
>
> <div class="content" data-expected-height=2000></div>
>
> </div>
>
> </td>
>
> </table>
>
> <div id="output"></div>
In your case 2, the table's height is 'auto'; the table-row's height is
'auto'. So, the minimum required height by content in cell or the
specified content 'height' applying to cell should be honored without a
problem.
Your test (with several small modifications):
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/Case2-container-respects-specified-height-cell.xht
I think this is a overflow-y: hidden bug in Chrome 41.0.2272.101. The
specified 100% height applying in div#container is honored. Overflow-y
declaration is not honored. What it seems I get with Chrome 41 is
'overflow-y: visible' instead. Chrome 41 behaves as if overflow-y:
visible was effective.
If I set overflow-y to auto, then Chrome 41 shrinks the div#container
width from 100px to 85px without rendering a vertical scrollbar. Firefox
36.0.4 keeps the width of div#container at 100px and does not render a
vertical scrollbar.
Gérard
> I'm happy to go with whatever makes sense for everybody so please
> regard
> this as an attempt to reduce the issues discussed in this thread down
> to
> two digestible test cases that we can attempt to agree a rendering for.
>
> Thanks,
> Robert
Received on Monday, 23 March 2015 23:21:35 UTC