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

[fantasai:]
> 
> Because this is what I wound up thinking about at 2am last night when I
> couldn't sleep...

I too think of run-ins when I can't sleep. 

> 
> Model is this:
>    - run-ins are always treated like elements with ''display: inline''
>    - except that they mangle the box tree thus:
>      * Run-ins are only allowed to be the first inline in a block,
>        or the first inline following other run-ins.
>        Thus an inline followed by a run in causes the creation
>        of an anonymous block boundary between the two,
>        but a run-in followed by an inline form a block together.
>      * If the last run-in in a sequence is immediately followed
>        (ignoring out-of-flows and white space) by a block,
>        the entire sequence gets shifted into that block.

I'd love to hear about all the use-cases that motivate run-ins. Without those
I can't form an opinion as to whether a proposal is good/bad. I've heard of
some in various meetings but if we're going to revisit this it'd be useful
to put them down on a wiki page.

Fwiw this sounds almost...understandable :)

> 
> This solves several problems:
>    * The behavior of the run-in is no longer determined by its contents.
>    * We don't have the weird discrepency between
>        <run-in>some</run-in>
>        <p>text</p>
>      where "some text" appears on one line but
>        <run-in>some</run-in>
>        text
>      appears on two lines.
>    * Multiple run-ins still run-in, so something like
>        <dt>implementer
>        <dt>implementor
>        <dd>(n.) Someone or something that implements.
>      can render as
>         *implementer, implementor* (n) Someone or something that
> implements.
> 
> Thoughts? bzbarsky, is this reasonably sane? :)
> 
> ~fantasai
>

Received on Friday, 20 July 2012 15:30:39 UTC