- From: Giovanni Campagna <scampa.giovanni@gmail.com>
- Date: Sun, 31 May 2009 21:49:38 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-style list <www-style@w3.org>
2009/5/31 Boris Zbarsky <bzbarsky@mit.edu>: > 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. Sorry, I meant that the part of rule one about discarding the box (and its related out-of-flow box) is superflous. The inline box itself is needed. >> 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. Sorry, my mistake: I only thought of whitespace-only boxes (assuming content wrapped in explicit boxes). Your proposal seems to describe what is implemented at the moment and so I support it. > -Boris > Giovanni
Received on Sunday, 31 May 2009 19:50:12 UTC