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

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

From: Bert Bos <bert@w3.org>
Date: Fri, 23 Jan 2009 20:41:33 +0100
To: www-style@w3.org
Message-Id: <200901232041.33967.bert@w3.org>

On Thursday 22 January 2009 19:48, Boris Zbarsky wrote:
> Bert Bos wrote:
> > 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. says that white space in the source doesn't generate anonymous 
inline boxes if those spaces would be collapsed away. That avoids that

      <p>First para...

generates two spaces before the first para. It also avoids that


creates an anonymous row with two spaces before the first row. But, 
strictly speaking, it doesn't avoid that

      <td>First cell...

creates an anonymous cell before the first one, because applies 
to *block-level* elements, of which TABLE is one, but TR is not.

So I retract that we don't need a rule. We do need to say something 
similar to for collapseable spaces inside a table-row(-group) 
or inline-table. Note also that doesn't say that the spaces 
create a box that has 'display: none', it says that there is no box at 

We need to say something somewhere that causes the spaces in

    <p style="display: table-row">
      <em style="display: table-cell">One</em>
      <em style="display: table-cell">Two</em>

to be ignored, but *not* the spaces in

    <p style="display: table-row">
      <em style="display: inline">Three</em>
      <em style="display: inline">four</em>

So, borrowing text from, I suggest we add the following at the 
end of the last rule in 17.2.1 ("If a child T of a 'table-row' box P is 
not a 'table-cell' box,[...]"):

    No such table-cell box is generated if it would contain only
    white-space that would subsequently be collapsed away according to
    the 'white-space' property.

And then remove rule 4½. I think that covers all cases. E.g.,

    <div style="display: inline-table">
      <p style="display: table-cell">Top left</p>
      <p style="display: table-cell">Top right</p>
      <p style="display: table-row">
       <i>italic</i> <b>bold</b> etc.

ignores the spaces before the <p> tags, but keeps the spaces before the 
<b>. (And those before the <i> as well, although they are not rendered, 
because they end up at the start of a line.)

> OK, but then what happens with this HTML markup?
>    <pre>
>      <table>
>        <tr>
>          <td>Some text</td>
>        </tr>
>      </table>
>    </pre>
> Without this rule, the required rendering would be equivalent to this
> markup:
>    <pre>
>      <table><tbody><tr><td>
>        </td></tr><tr><td>
>          </td><td>Some text</td><td>
>        </td></tr><tr><td>
>      </tr></tr></tbody></table>
>    </pre>
> which is NOT what any UA actually does, nor what any UA wants to do.

It's not valid HTML, so what UAs "should" do is not defined. (Depending 
on circumstances, they could, e.g., close the PRE before the TABLE, do 
as if the TABLE, TR and TD tags weren't there, or show a box that 
says "error!" My own software does the first. The validator suggests 
generating a BUTTON element around the TABLE. Tidy removes the <pre> 
tag and reinserts it after the table. It's hard to tell what browsers 
do from looking at the rendering.)

(Also the uses cases for applying 'white-space: pre' to a table seem 
rather contrived. If something reasonable falls out of the definition, 
that would be nice, but if not, I don't think that's a problem, as long 
as the case with 'white-space: normal' works as expected.)

But let's look at this modified example:

      <span style="display: table">
        <span style="display: table-row">
          <span style="display: table-cell">Some text</span>

And let's also assume this is SGML (HTML), not XML. (That means, 
concretely, that the ends of line on the 1st, 2nd, 3rd and 6th lines 
are ignored.)

The PRE creates a block box and the first content of that is two spaces.

Next comes a table box, which is block level, so the previous two spaces 
are, conceptually, wrapped in an anonymous block box.

Inside the table we first find four spaces. They constitute text and 
thus become an anonymous inline box. But we expected a table row box, 
so we open an anonymous one. That still doesn't allow placing the 
anonymous inline, so we open an anonymous table cell as well. Now we 
can place the anonymous inline with its four spaces.

Then we see a table row, so we close the anonymous table cell and the 
anonymous table row that we just created. We now start the second row 
of the table.

We see six spaces, which create another anonymous inline box. (Note that 
I ignore "rule 4½" here.) We are in a table row, so we need to create 
an anonymous table cell to contain them.

Next we see a table cell. So we close the anonymous table cell that we 
just created for the six spaces. We stay in the same row and open the 
table cell.

The element contains "some text", which becomes the content of this 
table cell. And then the table cell ends.

Now we see a newline and four spaces. They create a line break and an 
anonymous inline box. We are still in a table row and thus we need to 
create another anonymous table cell to contain them. That table cell 
thus has two lines of text: an empty one and one with four spaces.

The end of the SPAN signals the end of the table row, i.e., the end of 
the second row of the table.

After that </SPAN> is another newline and two spaces. But we are 
currently in a table element, so we need to create an anonymous table 
row again (the third row of the table) and an anonymous table cell. The 
newline and the inline box with spaces are put in that table cell.

The next </SPAN> is the end of the table.

The </PRE> then ends the block box.

So, schematically, we end up with:

    333333some text4

11 = an anonymous inline with the first two spaces of the PRE.
2222 = four spaces in the 1st cell of the 1st row of the table.
333333 = six spaces in the 1st cell of the 2nd row of the table.
4 4444 = a newline and four spaces in the 3rd cell of the 2nd row.
5 55 = a newline and two spaces in the 1st cell of the 3rd row.

Or with rules to show the structure of the table more clearly:

   |2222  |         |    |
   |333333|some text|4   |
   |      |         |4444|
   |5     |         |    |
   |55    |         |    |

It seems Opera only partially implements the SGML rule for suppressing 
newlines, so it has more newlines than expected (it only suppresses one 
of the four, it seems), but otherwise it appears to be correct.

Konqueror and Firefox seem to implement "rule 4½".

> >> Is there a space between the "AAA" and "BBB" or not?
> >
> > We certainly *want* there to be a space...
> Perhaps so.  There is one in Opera but not in Safari or Firefox, for
> what it's worth...
> > 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.
> Uh, no.  First of all, having the behavior depend on the white-space
> value is not acceptable;

Isn't that what 'white-space' is *supposed* to do?

> see above and earlier in this thread.  
> Second, I don't think we need English-centric concepts like "separate
> words" here.  I carefully wrote the text in such a way that the
> whitespace is between tags, not words.  If the language were Chinese,
> it would be separating nothing, but simply providing a way to
> organize the markup for better readability inthe file.

It doesn't matter whether the space is before or after a tag and it also 
doesn't matter whether the non-space characters are Chinese or Greek, 
the space collapsing rules are always the same. The spaces between the 
two SPANs are treated as if they were a single space, but are not 
ignored. If you are typesetting Chinese and you want to have spaces in 
the source but not in the rendering, you need to use the 
proposed 'discard' keyword from the Text module. (It's slightly 
different for newlines: they turn into zero-width spaces after 
Chinese characters. At least, that's what the draft for CSS3 says; in 
CSS 2.1 it's only a "may".)

> In any case, the current rules do in fact require that the box the
> text generates, if any, be wrapped in some other boxes as specified
> in this algorithm.  The question is whether the text generates a box
> at all.
> > 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.
> See above.  This argument doesn't hold, in my opinion.
> > We don't know yet if it adds a word space to the rendering; that
> > depends on whether there is anything more.
> This introduces issues with lookahead similar to what I just posted
> about, no?

Chapter 16 describes it in more detail. There is no lookahead involved 
in *parsing*, but when *rendering* a line you obviously need to 
consider a whole line at once, if not a whole paragraph. The space (or 
whatever object you have turned it into in the in-memory representation 
of the document) is either rendered as empty space (the width of which 
depends on the justification of the current line and the 'word-spacing' 
property), or not at all, if it happens to be at the beginning or end 
of a line.

> > 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.
> Not acceptable.  See above.
> > 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         |
> >
> >     +----------------+----------------+----------------+
> Yes, I know what the rules are meant to allow.  Unfortunately, they
> are not, as written, compatible with the way tables work in HTML. 
> That needs to be a higher priority than allowing the above.

The rules don't apply to HTML table elements. Or rather: they apply, but 
their if-clauses are always false. They apply when there are missing 
elements, which is never the case in HTML tables. Section 17.2.1 even 
mentions this fact explicitly.

Also, the rendering that some browsers used before CSS is not 
reproduceable in the CSS model. Maybe over time we'll find some 
solution, as browsers evolve and treat TABLE elements more logically 
and maybe CSS3 adds a new value to the 'table-layout' property. But for 
CSS 2.1 the working group decided that the state of current browsers is 
such that testing TABLE elements is not worth our time. Section 17.2 
says it like this: "User agents may ignore these 'display' property 
values for HTML table elements, since HTML tables may be rendered using 
other algorithms intended for backwards compatible rendering. However, 
this is not meant to discourage the use of 'display: table' on other, 
non-table elements in HTML."

So for CSS 2.1 we'll need the example with UL/LI to work, but we won't 
test any TABLE elements.

> Given the constraint of compatibility with HTML, the question is how
> much complexity the rules are willing to admit before we decide that
> this use case is not worth it.
> > 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.)
> I'm not saying it's not.  I'm questioning the ratio of usefulness to
> complexity.
> Let me put numbers to this.  Nearly half of the code that constructs
> the box tree and manages dynamic updates of various sorts in Gecko
> exists solely to implement this one section of the specification.  It
> doesn't even do so correctly (e.g. it's disastrous at handling
> dynamic mutations).  Making it do that correctly will involve not
> just more complexity but additional performance penalties in some
> cases.  The code is ugly and sin and could probably be shorter and
> simpler, but this section is a _huge_ source of complexity in box
> tree construction.  And the spec isn't even correct; see above.
> Is the use case really worth it?  Or would the other approaches you
> describe be better suited?  How common is the use case?
> It seems to me that the feature was added as a "that would be cool"
> thing without really thinking through the implications (heck, the
> fact that it's not compatible with HTML shows that), and that no one
> ever di the sort of use case analysis that's nowadays part of, say,
> the HTML working group process...

I can assure you a lot of thought went into the rules for anonymous 
table boxes. Nevertheless, many common cases of (XML) mark-up couldn't 
be fitted into the model and were postponed to what was then still 
called the Frame-based Layout draft (now turned into Template Layout), 
or left to a transformation language such as XSLT.

Many cases where people now are forced to use floats were meant to be 
handled by tables. (And I do handle them with tables, even if that 
means the rendering in IE is not optimal, because in other browsers it 
looks better than floats.)

A rule we applied in the design was that content should always be 
rendered (except when it was hidden with 'display: none', of course) 
and so any strange sequence of 'display' values should yield a useful 
result. That's why a 'block' inside an 'inline' isn't ignored, and 
ditto for 'inline' inside 'table'.

One difficulty that we never solved was how to render a DL as a table 
with two columns: DT on the left and DD on the right. (We lamented that 
HTML never got the DI element that was once proposed to group DT and DD 
elements together; like BODY, DI didn't actually have to be typed, but 
it would still be present in the tree.) The 'display: compact' solution 
isn't exactly the same, although it is useful, too.

> > If I understand you correctly, you want the above to not render at
> > all!
> As a simple option, yes.
> > 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.
> Except table cell display types are not interoperably implemented in
> UAs (e.g. IE before IE8 last I checked), so they can't use them
> anyway.

Many things don't work yet in some browser or other. And no style works 
at all if you use Lynx. Likewise, colors are lost if you print on a 
laserprinter. And hypertext doesn't work then either. That isn't 
necessarily a problem, or necessarily a big enough problem to give up 
on nice features in the browsers that it does work in.

> >> 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.
> Yes, any simple example works fine.  Want me to write you some
> slightly more complicated ones that don't?  My very first attempt
> over here with "white-space:pre" wasn't interoperable between Opera,
> Gecko, and Webkit (Opera did one thing, the others did something
> else), to say nothing of IE.
> In any case, I'm happy if the spec spells out exactly what simple
> cases we do want to support and EXACTLY how they should work, as long
> as this is compatible with how tables work in HTML.  But the current
> state of things is not acceptable.

It has never been a goal to describe what Netscape 4 did with 
HTML tables, let alone what it did with invalid tables. Not only didn't 
we believe we had the time to do it, we never even considered it 
useful. For a while that was implicit, but the spec now says it 

The CSS3 Table module will contain the legacy algorithm for computing 
table widths. Few people will be able to check if it is correct, so if 
you can help, that would be great.

There is also research going on at some universities into efficient 
algorithms that give better layouts. The results are promising and 
maybe they will be stable in time to be put in CSS3 as well. Then we'll 
have something like

    'table-layout: auto'
        The UAs choice of automatic width computation. The spec gives
        just a small set of constraint the algorithm must satisfy.

    'table-layout: fixed'
        The simple layout that gives each column the same width or the
        width explicitly set by the designer. It doesn't require laying
        out any content in order to compute the width.

    'table-layout: legacy'
        The Netscape 4 legacy. Mostly included for developers of new UAs
        that still want to mimic the old browsers on old content.

    'table-layout: some-name-yet-to-be-chosen'
        An efficient automatic algorithm that balances column
        widths consistently better than the legacy algorithm to create
        tables of near-minimal height.

  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 Friday, 23 January 2009 19:42:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:23 UTC