Re: [CSS21] Concern about anonymous table objects and whitespace

On Thursday 22 January 2009 15:34, Boris Zbarsky wrote:
>  > So, would a rule 4½ added to the anonymous box generation rules
>  >   http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
>  > that states
>  >
>  >   4½. If a child T of a 'table', 'inline-table',
>  > 'table-row-group', 'table-header-group', 'table-footer-group', or
>  > 'table-row' box is an anonymous inline box that contains only
>  > white space, then it is treated as if it has "display: none".

On looking at it it again, I think we made the wrong decision by adding 
this rule. We actually don't need it. If 'white-space' is 'pre', you 
don't wan't the space to disappear; and if space is being collapsed, 
you still need to keep the spaces between words, as the example below 
shows.

>  >
>  > solve the problem?
>  >
>  > ~fantasai
>
> OK, I'm looking at this again.  This might solve the problem but
> requires either various lookahead when constructing the rendering
> tree or creating, analyzing, and then possibly (and in fact probably)
> destroying rendering objects.  Further, it requires all this in the
> common case (HTML tables).
>
> And I'm not even sure whether it solves the problem, because I can't
> tell, by reading this rule, what the correct box tree is for:
>
>    <div style="display: table-row">
>      <span>AAA</span>
>      <span>BBB</span>
>    </div>
>
> Is there a space between the "AAA" and "BBB" or not?

We certainly *want* there to be a space...

The way I would process this example is as follows:

We see the DIV and open a table row box.

Next we see some white space. We are not preserving white space, so it 
is not contributing any content; it's just mark-up to separate words 
and as we haven't seen any words yet, we can simply ignore it.

Then we see an inline element, SPAN. According to the last rule in 
17.2.1, we thus need to open an anonymous table cell of which this SPAN 
becomes the first child.

The SPAN itself poses no particular problem, but at the end we encounter 
white space again. We are still not preserving spaces, but we did just 
see some inline stuff, so this white space marks the end of a word. We 
don't know yet if it adds a word space to the rendering; that depends 
on whether there is anything more.

Next we see another inline element. We add that to the anonymous table 
cell that we still have open. The inline element contains text, so now 
we know that the white space that we saw just before it indeed 
separates two words and will be rendered as a word space (or maybe a 
line break).

At the end of the SPAN we see some more white space. That ends the word 
we just saw.

Next we see the end of the table row, </DIV>. That means we can close 
the anonymous table cell and the table row. And as we haven't seen any 
more words, that last white space before the </DIV> won't be rendered.

If, as in the original example at the start of this thread, you 
set 'white-space: pre' on the DIV or an ancestor, then white space in 
the source doesn't serve as mark-up to separate words, but constitutes 
text of its own. In that case there will still be one anonymous table 
cell in the table row, but it will contain some additional, anonymous, 
inline elements before, after and in between the two SPANs.

>
> The more I look at this section and think about implementing it, the
> more poorly-thought-out it seems.  So I would like to propose
> alternate anonymous box generation rules (loose phrasing; can write
> up formally if desired):
>
> 1) Suppress all "misnested" boxes except 'table-row' inside 'table'.
> 2) Wrap runs of 'table-row' inside 'table' in a 'table-row-group'
>     (needed to deal with XHTML's not requiring a <tbody>).
>
> It feels like this would be much simpler to implement. 

The rules are meant to allow

    <ul style="display: table; width: 100%">
      <li style="display: table-cell">item 1
      <li style="display: table-cell">item 2
      <li style="display: table-cell">item 3
    </ul>

to render as

    +----------------+----------------+----------------+
    | item 1         | item 2         | item 3         |
    +----------------+----------------+----------------+

because, especially in XML, there are often not enough real elements and 
you need anonymous ones to make tables. (This doesn't handle all cases 
that you might want to turn into tables, you'll also need XSLT or the 
Template Layout module, but it's still useful.)

You can sometimes approximate the effect with floats or inline-blocks, 
but they don't align content on the first baseline, don't expand to the 
same height, and don't collapse borders...

If I understand you correctly, you want the above to not render at all!

Here is another case:

    html {display: table; height: 100%}
    body {display: table-cell; vertical-align: middle}

    <h1>Hey, look!</h1>
    <p>We're centered!

We should no doubt have an easier way to center things vertically in 
CSS3 ('block-foo-align: middle' or 'margin: stretch', see 
http://www.w3.org/Style/CSS/Tracker/actions/18), but meanwhile people 
use table cells.

> Interoperability on this section is already quite poor, so making
> this change might actually get us to CR faster.

The examples above actually work fine.

> whether it'll cause website compat issues....  Are sites relying on
> the
> currently-interoperable behavior?  If so, can we loosen the "suppress
> everything" condition enough to allow those sites to keep operating
> while still keeping the overall thing somewhat sane?



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 22 January 2009 18:28:56 UTC