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

Tab Atkins Jr. wrote:
> 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 >

The whole premise of CSS is to change the presentation without changing 
the DOM.  That's why people want to present lists as tables using this 
stuff in the first place, instead of just rewriting as a table.

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

I'd rather not, since it indicates that this stuff is in fact used in 
the wild, so adopting my proposal might not be practicable (in that a UA 
that shipped it would break pages).

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

Ah, true.

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

For what it's worth, the block-inside-inline handling is specified in 
the current CSS2.1 draft if you want to read through it.  ;)

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

Lookahead is required because when you get to an inline child of an 
inline after a block child of the same inline, you don't know whether to 
close the anonymous block you created or not.  The answer depends on 
whether there are any later block siblings of the inline you're looking at.

-Boris

Received on Friday, 23 January 2009 17:48:48 UTC