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

On Fri, Jan 23, 2009 at 11:47 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Oh, certainly.  CSS is not all-powerful (yet), though, and some
designs still require extraneous markup.  This isn't *necessarily* a
failing - it indicates that there is a problem to be solved, but not
necessarily that the current *attempted* solutions needs to be kludged
into solving that problem.

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

Note, though, that the [article that author references][1] actually
marks up their example correctly, with the <ul> as table and the <li>s
as table-cell.  If other people are using this article as inspiration,
they'll at least have correct code to copy/paste from.  The author in
question is in trouble because he modified the markup substantially
further.  This means that he wasn't just blindly copy/pasting (though
he wasn't thinking very much, or else he would have used text-align),
which means that he would be amenable to playing around with the code
until it *did* work.

Given a slight change to my suggested algorithm (making rule 4
generate an anonymous table block rather than suppressing its
contents), his example could also have been done merely by changing
the <ul> to table-cell (thus forcing it to generate a table-row block
by rule 1, a table-row-group block by rule 2, and a table block by
rule 4, which then allows it to pass the later pruning rules.)

[1]: http://www.cssplay.co.uk/menus/centered.html

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

Heh, I'm not familiar with these more basic things.  Thanks for the pointer.


On Fri, Jan 23, 2009 at 11:50 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> 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.
>
> I think we have to be very careful about ignoring things that would break
> existing layouts.

Of course!  I question, though, how common a bare table block with
inappropriate children is, though.  As noted, the article that the
author in question took his technique from does it *correctly* with a
table block having table-cell children.

In the end, though, I believe that suppressing inappropriate children
is the correct way to go, and am banking on the hope that we can
derive decent repair algorithms to keep most/all code in the wild
still working as intended.  The algorithm I outlined from Boris'
suggestions earlier, once amended to generate an anonymous table in
rule 4, will handle most of the weird markup we've run into so far.
The referenced author's markup would still be bad *as written*, but I
don't have any idea how common it is to see that specific pattern (I
suspect it is rare).  Repairing markup like that will require the
lookahead that Boris wants to avoid, however, and requires a good rule
about how to treat whitespace within a table.

I *suspect* that by far the most common 'weird' use of the table-*
display types will be people placing table-cells in inappropriate
places, but the current repair rules fix those issues.  Does anybody
know if other weird uses are common, similar to the existing examples
in the css table spec?  (Both of those examples would render
incorrectly with my algorithm.)

~TJ

Received on Friday, 23 January 2009 18:19:41 UTC