Re: [css3-box] run-ins: an alternative model

On 8/7/12 8:20 PM, fantasai wrote:
> On 07/19/2012 12:00 PM, Boris Zbarsky wrote:
>> So any time a run-in is not part of a sequence of run-ins at the
>> beginning of a block and not part of a sequence of run-ins
>> that are followed by a block it gets moved into the following block?
>
> I read the question, but can't make sense of it. :/

I think I was trying to rephrase the conditions under which run-ins 
generate anonymous block boxes around themselves.  Those conditions seem 
to be:

1)  The run-in is not part of a sequence of run-ins at the
     beginning of a block.
2)  The run-in is not part of a sequence of run-ins that are
     followed by a block.

If both conditions hold, the run-in requires a new block box.  (After 
itself, presumably, and then runs into it?  What kids does the new block 
box have?)

That is, what does "not allowed" mean in terms of the box handling that 
needs to happen?

> Hm, interesting question. I suppose you could move the entire sequence of
> run-ins and out-of-flows and anonymous white space nodes into the block.
> Then the ordering stays the same, and you don't have to worry about
> splicing the list.

That's a pretty noticeable behavior difference for the out-of-flows from 
the run-in not being there, right?  I'm not convinced this is desirable 
behavior...

>      * If a run-in is preceded by an inline box (ignoring any anonymous
>        inline boxes containing only collapsed white space),
>        then it forces the creation of an anonymous block boundary
>        between it and the preceding inline.

I'm not sure this works, for two reasons:

1)  In a sequence of run-ins, a previous one would trigger this for a 
later one, right?

2)  "an anonymous block boundary" needs to be defined.  There are 
several different ways to do this which may not be equivalent when 
floats are around (e.g. whether anonymous blocks get nested or not).

-Boris

Received on Wednesday, 8 August 2012 00:32:30 UTC