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

On Fri, Jan 23, 2009 at 10:09 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>
>> Well, only if you're throwing around table-* display types, which
>> despite their usefulness are still definitely minority display types
>> (and I expect them to stay that way).
>
> Interestingly enough, I actually came across a use case my proposal would
> break this morning.  See
> http://stackoverflow.com/questions/471636/centered-ul-wont-expand-horizontally-in-ff-opera-works-in-safari-ie6-7-8
> (which links to an example page at
> http://deadguy.reliccommunity.com/stuffbox/testinggrounds/display-table.html
> in case the stackoverflow page goes away).
>
> The markup basically looks like this, stripped down:
>
>  <ul style="display: table">
>    <li style="display: inline-table">
>      <h1 style="display: table-cell">Some header text</h1>
>      <dl style="display: table-cell">
>        <dt style="display: inline">Something</dt>
>        <dd style="display: inline-block">Something else</dd>
>        <dt style="display: inline">And more</dt>
>        <dd style="display: inline-block">And yet more</dd>
>      </dl>
>    </li>
>  </ul>
>

That markup is silly.  His *goal* is to have the <li>s flow inline,
and center themselves within the containing block.  To accomplish
this, he wraps the whole thing in a fixed-width containing <div>, then
makes the <ul> display:table solely so it will shrink-wrap the <li>s
and thus can use auto-margins without a specified width.  He could
accomplish this just as easily by dropping the containing <div>,
giving the <ul> a specified width, and setting text-align: center on
it (and I suggested exactly this course of action to him on the Stack
Overflow thread).  This also allows Firefox to correctly move the
blocks around when he inserts a new <li> (currently it won't resize
the <ul>).

The only reason this might not work is if you *really* want a
shrinkwrapped containing block around the inline blocks, frex to
provide a background.  In that case, however, you can *right now* just
add another containing <div>, make *it* display:table with auto
margins, and then make the <ul> display:table-cell.  In the future
we'll have the ability to *tell* blocks to shrinkwrap, and in the
limit he can use ul::outside to generate the display:table block
through CSS rather than inserting it into the markup.

So, this isn't a *real* use-case, in that it does not require any
changes to CSS to get the desired rendering.  I'd rather ignore it.
If this type of markup (a display:table block immediately followed by
inappropriate children) *is* necessary to deal with, though, then we
do need to sort out whitespace issues so that we can accurately tell
when we need to auto-wrap the contents of a table block and when we
don't.

> except there are several such <li> blocks.  So it seems like this sort of
> thing really is being used in the wild, and this isn't even a completely
> ridiculous use case (just want a table with the list-items as cells, but
> each list-item is also a table itself).

Not quite.  His desired rendering (and the actual rendering with
current browsers) is for all the <li>s to sit in a single large
table-cell.  You get something like:

<ul> (table)
  <anonymous-row>
    <anonymous-cell>
      <li/> (inline table)
      <li/> (inline table)
      <li/> (inline table)
    </>
  </>
</ul>

If he *did* want the layout you talk about (with each <li> in a
separate table-cell), I don't think there's a reasonable way to infer
that.  It's not difficult to create such a rendering, though; just
make the <li>s table-cell, and wrap their contents with an
inline-table div.

>> I can see problems in the case that, say, a display:table container
>> gets switched to display:block, perhaps by script, which would cause
>> its contents to be completely suppressed.  Is it possible for CSS to
>> do a display-orphaning, analogous to the normal table orphaning but
>> without actual DOM changes?
>
> I don't think that would be desirable....

Eh, it would mirror the behavior of misformed <table>s, which is why I
suggested it.  At least then it works in a way that authors are
relatively familiar with (or rather, can at least understand by
example - before doing some tests the other day I wasn't sure of
exactly how current browsers handle orphaning), even if it *is* still
undesirable.

>>> He also pointed out that there is existing spec text that requires the
>>> sort
>>> of lookahead that makes me unhappy, and in particular that blocks inside
>>> inlines require it.
>>
>> Is that truly a display issue, or is that part of the HTML algorithm?
>
> Display.  We're talking things like:
>
>  <div style="display: inline">
>    <div style="display: block"/>
>  </div>

Ah, gotcha.  Here we move beyond my personal knowledge, because I
don't know the technical details of how current CSS engines group
things into boxes.

Speculating, this doesn't *seem* like it requires significant
lookahead, but that is probably me thinking in terms of the html
parsing.  In that case you're processing the code as a stream, and
have the ability to just 'pinch off' an element when you have
misnesting.  It seems like CSS instead works on a tree (one being
constructed on the fly, at least during page-load, but still), and so
lookahead is required in order to correctly state whether a given
element forms a particular type of block.  Is this roughly correct?

~TJ

Received on Friday, 23 January 2009 17:32:33 UTC