- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 23 Jan 2009 09:52:55 -0600
- 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. Cool. > 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). ~TJ
Received on Friday, 23 January 2009 15:53:33 UTC