- 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