W3C home > Mailing lists > Public > www-style@w3.org > May 2009

Re: [CSS21] Proposal for a replacement for section 17.2.1 (table anonymous objects)

From: Giovanni Campagna <scampa.giovanni@gmail.com>
Date: Sun, 31 May 2009 21:49:38 +0200
Message-ID: <65307430905311249x4fdaed01u6b5e3b8ff9abb7a0@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT