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 09:52:55 -0600
Message-ID: <dd0fbad0901230752t68755010w71577660cd2bb302@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org

On Fri, Jan 23, 2009 at 9:28 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Tab Atkins Jr. wrote:
>>> 8) Change rule 8 to say that the child box should be suppressed.
>> There is no rule 8?  (At least, not in the draft I'm looking at, from
>> the link in your original mail to this thread.)
> Er, sorry.  I must have been reading
> http://www.w3.org/Style/Group/css2-src/cover.html when I wrote this (the
> group-internal editor's draft thing.
> It's identical to what you see in this part, except that there is a rule
>  inserted between the current rules 4 and 5 to try to deal with the
> whitespace issue.  So rules 1-4 are the same, rule 5 is the whitespace
> thing, and the later rules are shifted down by one compared to the last
> public draft.

Ah, k.

>> So it seems that your proposed algorithm boils down to these rules
>> (padded out for exactitude, necessary because purging some of the
>> anonymous-box creations violates some assumptions about table
>> validity):
> ....
>> 3.  If the parent P of a 'table-column' box T is not a
>> 'table-column-group' box, a box corresponding to a 'table-column-box'
> 'table-column-group' at the end there.

Curse my ham-fists!

> Other than that looks like what I was proposing, yes.


> I spent some time talking to David Baron about this yesterday, and he
> pointed out that one problem with this approach is that it makes it easy to
> accidentally make things disappear, with no obvious reason (from the
> author's point of view) for it.  This could be especially problematic if
> there are multiple interacting stylesheets.

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

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?  That would produce *unexpected* results
in the scenarios alluded to, but at least they wouldn't be of the
"where did my page go" variety.  Basically, whenever the rules would
say "suppress a box", they would instead say "ignore the display
value", and possibly display it before/after the remaining valid
display:table-* elements.

Going with this, we probably would want to extend the 'repair' rule
somewhat, so that rule 4 in my suggested algorithm would generate an
anonymous table in an analogous way to the existing rule 4 (or 5 in
your draft).  Then the "correct downwards" rules would instead
'orphan' blocks that didn't conform to their rules.

(I would note, though, than an author without a proper CSS debugger
like Firebug or the IE8 Developer Tools can only blame themself if
they hit a difficult-to-debug issue.  Most issues become trivial when
you can just select an element in the DOM and see exactly what rules
are applying to it and where they come from.)

> 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?
That just causes the inlines to prematurely close, right?  (And reopen
within the block, iirc?)

> So another course of action might be to keep this text as it is, fix the
> continuing ambiguity wrt whitespace handling, possibly adjust rowgroup and
> colgroup behavior, and see what things look like implementation-wise in a
> bit...  If the whitespace thing is somehow clearly defined, I can at least
> try giving implementation a shot and see whether I really run into serious
> issues.

If we can find a good way to deal with whitespace, I'm in favor of
extending the repair algorithm further.  My intention is just to get
this defined clearly and simply.  I think that the whitespace issue is
the only reason the "correct downwards" rules can't easily repair, and
must instead suppress (or orphan).

Received on Friday, 23 January 2009 15:53:33 UTC

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