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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 09 Aug 2010 22:28:02 +0200
Message-ID: <4C6064D2.8030604@moonhenge.net>
To: www-style@w3.org
CC: Peter Moulder <peter.moulder@monash.edu>
Peter Moulder wrote:
> 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 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.
> 
> 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
> explicitly.

It's a very fair point.  Whilst mentioning them was already as
editorially risky as it is now to remove that mention (eg, see below), I
too am now more confident that it doesn't actually matter whether we
define the behaviour of a block container box in terms of the presence
of run-ins or not.

> 9.2.1.1 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 9.2.1.1 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 9.2.1.1 as examining the box tree's final state,
> because then there wouldn't be any inline boxes that contain a block box.

Thanks; it's an interesting slant.  I'd always hoped that the "timing"
issue was a purely editorial device which works well because it reflects
many people's mental model of how the document is rendered, whilst also
playing nicely with incremental layout.  It's not my impression that
normative descriptions of behaviour are permitted to implicitly or
explicitly depend on it.  Clarification of the actual intent here would
be good!

I also acknowledge that the spec really does talk as if the run-in
generates a "run-in box" whose nature is unknown at the start but
becomes know later.  For example, in the description of the 'display'
property:

   # run-in
   #   This value creates either block or inline boxes, depending on
   #   context. Properties apply to run-in boxes based on their final
   #   status (inline-level or block-level).

and from 9.5.2 ('clear'):

   # For run-in boxes, this property applies to the final block box to
   # which the run-in box belongs.

(a sentence which makes no sense, although I think I know what it's
/trying/ to say).


> One reason to read 9.2.1.1 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 9.2.1.1 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".

I'm pretty sure it does mean the latter, though, which would mean that
9.2.1.1 can be done "late".

Even if not, there's a complementary problem if we apply 9.2.1.1 first:
if a block box consists of a run in followed by inline content, the
inline content becomes wrapped by anonymous block box purely due to the
presence of the run-in.  If it later turns out that the run-in doesn't
contain a block box, then becomes the first inline box of the anonymous
block.  But then the anonymous box is superfluous and it was arguably a
mistake to have added it in the first place.  (I don't think it's
intended that we end up with the anonymous block wrapper in the final
state.)

The trouble is, the timing device doesn't hold together very well.


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 9 August 2010 20:29:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT