- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 31 May 2009 15:15:27 -0400
- To: Giovanni Campagna <scampa.giovanni@gmail.com>
- CC: Brad Kemper <brad.kemper@gmail.com>, www-style list <www-style@w3.org>
Giovanni Campagna wrote: > Reading again the algorithm, I see that a box can be discarded if one > of the following are true: > - it is a child of table-column > - it is a child of table-column-group, and it is not a table-column > - it only contains one _discardable_ (whitespace) box (and it has a > table-*-group, table, inline-table, table-row display) > - it is out-of-flow and its _related inline box_ (a concept I > personally dislike) is discarded That's correct. (Note that the related inline box actually exists in Gecko; it's used for handling auto-offset positioned elements, since those need the layout engine to keep track of where the box would have been if it were still in-flow. I can't speak to whether it exists in other UAs too, but I strongly suspect it does, given the behavior on the table testcases.) > This means that rule 1) is superflous, since the _related inline box_ > of a out-of-flow box is never _discardable_ Rule 1 is needed to address the third technical issue I describe in the preface to my proposal in the original mail. If the related inline box were discardable (or heck, if it didn't exist), then the rendering on that testcase would be quite different from that observed in browsers. > so out-of-flow boxes can > be discarded only if children of table-column / table-column-group Correct. > (assuming that elements with display:none generate no boxes for them or their > children / descendants). CSS 2.1 section 9.2.4 clearly says: none This value causes an element to not appear in the formatting structure (i.e., in visual media the element generates no boxes and has no effect on layout). Descendant elements do not generate any boxes either .... Please note that a display of 'none' does not create an invisible box; it creates no box at all. > A final solution which removes the _discard_ concept is just to say that > - The computed value for display is none if the parent's display is > "table-column", or if the parent's is "table-column-group" and the > specified is not "table-column" > - The "white-space" property does not apply to table, > table-header-group, table-row-group, table-row display types, and it > is always processed as "normal" (collapsing and discarding all > whitespace not explicitly wrapped in container elements) That's not equivalent to my proposal, and the difference is in fact tested by some of the tests I linked to. For example, this testcase: <!DOCTYPE html> <body style="display: table-row; white-space: pre">a b</body> shows two spaces between the 'a' and 'b' with my proposal but only one in yours. One example of a test from the test suite that exercises this looks like: <!DOCTYPE html> <span style="display:table-row; white-space: pre"><span style="display: table-cell">a</span> bc <span style="display: table-cell">d</span></span> This renders as "a bc d" if my proposal is implemented; it would render as "abcd" with your proposal, I believe. -Boris
Received on Sunday, 31 May 2009 19:16:07 UTC