- 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