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

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 absolute minimal markup required to create a table is
<table><td>foo</td></table> (well, I may be able to omit some end
tags, but I don't like doing that).  So, at bare minimum,
display:table-* elements should work the same.  They *require* a
display:table container, but the only required table-* child is
table-cell.

That covers the latter half of Boris' proposal.  The former is also
easy to address.  In normal <table> usage, the markup space between
<table> and <td> is a no-man's land where *nothing* is allowed except
the other table elements.  Anything *other* than a table element
placed in this area in the markup gets orphaned in the DOM, appearing
as an anonymous text node preceding the <table>.  By the time CSS sees
it, the table is pristine, with everything sitting perfectly in their
<td>s and (possibly automatically-created and anonymous) <tr>s and
<tbody>s.  (The one exception to this is whitespace nodes, which are
ignored.)

Since orphaning is, I would gather, *never* intended, we can regard it
as *always* a mistake.  HTML has to deal with it anyway (which is why
the orphaning algorithm exists), but in CSS we can *probably* just
treat it like the mistake it is and ignore it, exactly as Boris
suggests.  As he also points out, this allows us to trivially match
<table>'s treatment of internal whitespace nodes as well.

Unless there can be found any examples where this would break existing
markup significantly, I say go with this.  It should simplify both
implementations *and* specs, making it easier for authors to
understand what's going on.

~TJ

Received on Thursday, 22 January 2009 20:18:47 UTC