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

Peter Moulder wrote:
> On Sun, Aug 08, 2010 at 09:24:30PM +1000, Peter Moulder wrote:
> 
>> Regarding the more general problem of specifying the interaction between
>> these two sections, the complicated behaviour I've seen makes me inclined to
>> wait until we're looking at adding the text that describes the box tree (what
>> boxes are siblings or children of what other boxes).
> 
> I ought to be more explicit there: part of the reason I suggest the above
> is in case it ends up that interactions among the various anonymous block
> transformations and run-in manipulations and pseudo-element things and
> generated content (such as with list-style-position:inside markers) get
> specified as part of the description of box tree generation.  I would expect
> that at least some of these things happen as part of generating boxes in
> existing implementations.

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 9.2.1.1 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.  Hence it's appropriate to drop the
reference to run-ins in 9.2.1.1, even if it's not yet clear or fully
defined exactly where and under which conditions those boxes should be
generated.  It's not the job of 9.2.1 to describe every possible way
that a block-level box can be generated, for example.  Rather, its
primary purpose is to explain how block-level boxes behave.

If, on the other hand, the nature of display:run-in changes in future
so that certain boxes are generated that behave differently from
block-level or inline-level boxes (and I sincerely hope that this will
not happen) then 9.2.3 can be changed, and expanded to describe this new
type of box.  9.2.1 and 9.2.2 would only need to be changed if the
existence of this new type of box meant that the various box terminology
defined therein would be out-of-sync.

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

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 8 August 2010 14:39:33 UTC