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

On 08/07/2012 05:32 PM, Boris Zbarsky wrote:
> 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?

So, I removed the "not allowed" bit :)

>> 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...

I think it's less weird for the out-of-flows to stay between the element's
they're between. It also seems easier from an implementation perspective,
since you can preserve the painting order through the box-tree order as
usual, no?

>> * 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).

How's this?

     * If a run-in is preceded by an inline-level box that is not
       a run-in (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,
       as if it were immediately preceded by an empty anonymous block.

~fantasai

Received on Wednesday, 8 August 2012 01:45:09 UTC