W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [CSS21] anonymous blocks vs run-ins; and Distinguishing block boxes proposal

From: Peter Moulder <peter.moulder@monash.edu>
Date: Mon, 09 Aug 2010 09:01:19 +1000
To: www-style@w3.org
Message-id: <20100808230119.GA25046@bowman.infotech.monash.edu.au>
On Sun, Aug 08, 2010 at 04:37:48PM +0200, Anton Prowse wrote:

> Whilst I agree that various unresolved complications concerning run-ins
> still remain, I'm not sure why this leads you to the following conclusion:
> >On Wed, Jul 21, 2010 at 12:16:54AM -0700, fantasai wrote:
> >
> >>...
> >>Section Anonymous block boxes
> >>
> >>  # In other words: if a block box (such as that generated for the DIV
> >>  # above) has another block box or run-in box inside it (such as the P
> >>  # above), then we force it to have only block boxes and run-in boxes
> >>  # inside it.
> >>
> >>  s/another block box or run-in box/a block-level box/
> >>  s/only block boxes and run-in boxes/only block-level boxes/
> >
> >[...] the behaviour that I've seen makes me inclined to suggest that
> >the explicit mentions of run-ins should be retained in each of those cases:
> >although the evidence isn't unanimous, the principle of avoiding making
> >unintended normative changes suggests that the explicit mentions of run-ins
> >should be retained for now at least.
> Currently, 9.2.3 says that display:run-in causes various block-level or
> inline-level boxes to be generated.

I was trying to writing a long message about why it might make a difference to
mention run-in boxes explicitly, and was hoping that it would be enough just to
say "it might make a difference, so let's retain that for the moment": it would
appear that the new definitions make no difference to whether run-in boxes need
distinct mention, so without looking into it we should err towards trusting the
initial text's author's judgement that it's worthwhile mentioning them

So I would hope that people could just stop reading here, without spending any
time thinking about whatever arguments I give from here onwards. describes making changes to the box tree (breaking existing boxes for
example), and similarly 9.2.3 uses the language that a run-in box "becomes"
another box (as distinct from a run-in element generating a block-level or
inline-level box to start with).  So both texts describe the box tree not as a
unique thing for a document but as something that changes over time, where
display:run-in elements initially generate plain run-in boxes that are neither
block-level nor inline-level, and examines the box tree as it exists in
one state (where an inline box still contains a block box, and where a run-in
box might not yet be a block-level box) and makes decisions based on that
initial state.  We can't read as examining the box tree's final state,
because then there wouldn't be any inline boxes that contain a block box.

One reason to read as specifically applying before rather than after
run-in transformations is that we presumably want the case where a run-in
element contains a display:inline element that contains a block-level element
to result in the generated box not running in, even the box doesn't contain (as
a child) any block-level boxes until after rules have applied.  The
word "contain" in CSS box-tree/element-tree contexts fairly consistently means
"as a child"; it can't be read as "as a descendent" without getting into
trouble with inline-block; while "as a descendent but only within the same
block formatting context" just isn't a natural english reading of "contains".

Mirroring the "timeline" argument is the corresponding practical reason: that
real implementations do in fact make changes to the box tree one change at a
time, and explicit mentioning of run-in boxes makes it more likely that they
will be handled in the way the author of that wording in the spec intended.

Remember in any case that I'm not saying so much that I think that that text
should in the final version be worded exactly like that, but rather that
we should avoid introducing an accidental change in the meaning when we aren't
examining that aspect at the moment.

If you like, word it as

  | (or run-in boxes)

if you think that mention of run-ins is redundant.

> I see it as an editorial error that run-ins were ever even mentioned in
> 9.2.1.

I haven't looked at the history, but my guess is that that part of the text was
drafted by one of the implementers of run-in boxes, and was aware that in their
implementation they needed to check for run-in boxes explicitly as distinct from
block-level boxes, and that mentioning run-in boxes explicitly is thus an aid
to interoperability, which at the moment is our primary concern in CSS2.1

I can see that it's good to avoid explicit mention of different types of box to
avoid repetition of the problems where different parts of the spec become out
of sync with each other (as with inline-block).  And maybe we could achieve
that by changing the definition of block-level to be explicit that it includes
any run-in boxes that will become block-level boxes in the final box tree
(though such a future-knowing definition would make me nervous about whether
it's well-defined in the first place: e.g. if we say "make change X depending
on what the future is" then I would be worried about whether change X can
affect that future state; and the changes in certainly have the
potential to affect the application of 9.2.3).

But before we look carefully at run-in boxes (and looking at run-in boxes does
indeed need rather careful examination), I suggest we accept the judgement of
the initial author in mentioning run-in boxes explicitly.

Received on Sunday, 8 August 2010 23:02:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:49 UTC