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

On Mon, Aug 09, 2010 at 10:28:02PM +0200, Anton Prowse wrote:
> 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.

Do people (Anton particularly) agree that explicit mention of run-ins does
serve practical purpose, that retaining some mention of run-ins is more likely
to result in the desired interpretation for at least some readers?
The excerpts that Anton identified do add weight to a reading where explicit
mention would be desirable.

I've just checked that the spec contains few enough mentions of `run-in' in
normative text that one can briefly read them all within a minute or two, so I
think the situation is quite different than trying to read all mentions of the
words `inline' or `block' to find whether the text is correct for the addition
of the value 'inline-block'.

Without wanting to look into run-ins more generally at the moment,
here are results for some tests I did on what behaviour is currently implemented
in Webkit and Opera [at least in older versions of them].  Interpret them as
element trees showing computed value of 'display'.

  block
    run-in     Runs in.  The simplest case.  Though note that already this
    block      shows some benefit of retaining on of the two explicit mentions
	       of run-in boxes: it clarifies that the run-in box doesn't get
	       wrapped in an anonymous box, even though it's not a block-level
	       box.  Yes one can still read the text as correct for this
	       example without mentioning run-ins explicitly, but at least
	       it helps.

  block
    run-in     Doesn't run in.  Nothing interesting here, just a sanity check.
      block
    block

  block        Anton's example.
    run-in     Doesn't run in.  (I'm fairly sure this is what the author
    inline     of 9.2.3 expected to see.)

  block
    run-in     Doesn't run in.
      inline
        block
    block

  block
    run-in            Runs in.  [Though, bizarrely, the inline-block
      inline-block    disappears in the version of Webkit that I tested;
        block         which is strange enough that I'd consider running
    block             valgrind or similar.]

  block
    run-in     Doesn't run in
    inline
      block

That last example is particularly interesting, and I believe it conflicts with
9.2.3 if one reads 9.2.3 as just making statements about the final box tree:
the run-in box doesn't contain a block[-level] box, so (1) doesn't apply; and
a sibling block box (that does not float and is not absolutely positioned)
follows the run-in box [viz. the anonymous block box], yet the run-in box
hasn't become the first inline box of that block box.

That's not to say that it would be impossible to change the text to avoid this
conflict, but I hope it does add a little weight to the argument that
retaining explicit mention of run-ins will be helpful to some readers,
and that it also shows that run-ins have non-obvious behaviour even
before we've looked into how those two sections together interact with
various other parts of the spec that either modify the box tree or whose
behaviour depends on the box tree (such as counters, list item numbering,
anonymous table box creation, list-style-position:inside, and so on).

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

If by that Anton means that the timing is underspecified, then I agree.
However, at least it isn't inconsistent.

(I think Anton was trying to show that although the current text is unclear,
the timing probably isn't as simple as "apply one of these sections to all of
the tree before applying the other section to any of the tree" for most
readings of the spec, and I would tend to agree with that.)


We now have several arguments for retaining explicit mention of run-ins in
9.2.1.1 until we next revisit these two sections.  So I hope we do retain
their mention for now; though it's clear that we'll need to re-examine
their interaction sooner or later, so I intend not to spend any more time
discussing this temporary wording.

pjrm.

Received on Tuesday, 10 August 2010 18:35:24 UTC