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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 23 Jan 2009 14:54:17 -0600
Message-ID: <dd0fbad0901231254m238ce636w8a1f47562713ec43@mail.gmail.com>
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org

On Fri, Jan 23, 2009 at 1:40 PM, Bert Bos <bert@w3.org> wrote:
> On Thursday 22 January 2009 21:18, Tab Atkins Jr. wrote:
>> On Thu, Jan 22, 2009 at 1:01 PM, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
>> > Thinking about your use case some more, what if we allowed
>> > inference of table rows between tables and cells, say, but didn't
>> > show any non-table-related anything that's a direct child of a
>> > table, table-row-group, or table-row?  Would that cover enough of
>> > the use cases? It would certainly cover both of yours.
>> >
>> > As far as that goes, we could also require that any table-row,
>> > table-row-group, or table-cell needs to have a table somewhere
>> > around it. That would still cover your use cases, but be
>> > significantly simpler.
>> After thinking on it a bit more (and a quick off-list discussion with
>> Boris), I think this is exactly what we should do.  Not only is it
>> simple, but afaict it matches current <table> behavior perfectly.
> The counterexample is this: I want to render the following three lists
> (days, persons and places) as a single 4x3 table.
>    <report>
>      <title>Week 13</title>
>      <days>
>        <item>Monday</item>
>        <item>Tuesday</item>
>        <item>Wednesday</item>
>        <item>Thursday</item>
>      </days>
>      <persons>
>        <item>Joe</item>
>        <item>Ann</item>
>        <item>Sue</item>
>        <item>Ray</item>
>      </persons>
>      <places>
>        <item>Oslo</item>
>        <item>Rome</item>
>        <item>Lisbon</item>
>        <item>Sofia</item>
>      </places>
>    </report>
> I can do that with a style sheet like this:
>    title {display: block; font-size: large; margin: 1em 0}
>    days, persons, places {display: table-row}
>    item {display: table-cell}
> There is no element corresponding to the table box.

In my revised proposal, this would indeed work.  The table-row blocks
would generate a single wrapping table-row-group block, which would
then generate a wrapping table block.

(Edit while writing: Boris suggests making <report> a table block, and
<title> a table-caption block.  This would likely work as well.)

As far as I can tell, the only real difference between my suggested
algorithm and the existing algorithm is what happens when there is no
table-cell block between a table-block and a non-table-* block.  The
second example in the 2.1 spec illustrates this well with:

  <ROW>This is the <D>top</D> row.</ROW>
  <ROW>This is the <D>middle</D> row.</ROW>
  <ROW>This is the <D>bottom</D> row.</ROW>

My proposal simply suppresses the contents of the <row> tags.  (A
'transpose' or 'column-major' setting would fix this by allowing the
<row> elements to be table-cell and the <stack> to be table-row.)

Another illustration of the difference is:

wrapper { display: table-row; } (or display:table, whatever)
cell { display: table-cell; }

The 2.1 algorithm would wrap Foo and Baz in anonymous table-cell
boxes.  Mine would simply suppress them.  Does this occur in the wild?
 More on this in a sec.

> 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.

Mostly true, but only because the html parser cleans up the DOM for
you before CSS sees it.  Given the following:


You get a table with one cell (containing "Bar"), and the words "Foo"
and "Baz" orphaned as anonymous inline boxes preceding the table.

(Note as well that, at least in FF3.0, there is also still a text node
containing a newline within the table, preceding the <td>, which is

In other words, the html table-parsing algorithm just gives up on such
markup and kicks it out of the table.  My proposal analogously
suppresses such elements.  The question is if there is much in the
wild depending on the 2.1 treatment, because if not, the faster we can
declare such markup bad and stabilize closer to <table> behavior, the
better.  I don't think the typical author will appreciate that the
difference in behaviors between <table> and display:table blocks in
this area is due to magic <table>-specific behavior that can't ever be
reproduced in CSS.

(I think Boris is leaning more towards parsing that as a three-cell
table, but still clearing up just what the hell we're supposed to do
with the internal newlines.)

Received on Friday, 23 January 2009 20:54:52 UTC

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