Re: [CSS21] display:run-in clarifications

Bert Bos wrote:
> Here is proposed text to replace the first paragraph and the numbered 
> list in 9.2.3 
> http://www.w3.org/TR/2009/CR-CSS2-20090423/visuren.html#run-in
> 

I prefer the term "in-flow" (or equivalent) to the phrase "not floating 
and not absolutely positioned".  The latter phrase does not appear 
anywhere else in the chapter, whereas the "in-flow" (or equivalent) 
appears adjectivally in several places.


Your proposed changes support the following lazily-described philosophy 
(which I state mainly for my own benefit):

1) If there are any displayed in-flow block-like boxes inside a 
(pseudo-)element E with display:run-in, then the element cannot run in 
and instead is displayed as a block.

2) E can only run into in-flow elements specified as blocks or list-items.

3) E can only run into a subsequent sibling.

4) E can only run into its nearest suitable sibling.

5) The presence of out-of-flow elements between E and its nearest 
suitable suitable sibling do not inhibit E from running in.

6) The presence of unsuitable in-flow siblings between E and its nearest 
suitable sibling does inhibit E from running in.

7) If E does not run into some box then it has block-level display.


I'm not completely convinced by point (4).  For example, given the markup

<h2>I want to run into some text<h2>
<p></p>
<p>Some text</p>

I think I would like the heading to run into the second paragraph, 
provided the empty paragraph has zero border box area. (Probably the 
first empty paragraph appeared because the HTML generator didn't have a 
strict enough clean-up routine when content was carelessly entered. This 
kind of thing is *very* common.)  Note that if both paragraphs are 
stylistically identical then the empty one is not visible in the display 
thanks to margin collapsing.  Actually, should we even skip over the 
empty paragraph if it has /non/-zero border box area?


In response to the issues you raised:

Issue I:  I, too, see no typographic motivation for elements running 
into tables.


Issue II:  I rather like the idea of multiple run-ins, and I don't see 
any immediate typographical argument against it.  If it were permitted, 
the operation would of course be non-associative;  you suggest that 
run-ins should run in from the left, but I prefer that they run in from 
the right so that several consecutive run-ins all run into the same 
block.  I also agree that if the last run-in were displayed as a block, 
the previous run-ins should run into that block.


Issues III and IV:  I would prefer it if running in were not restricted 
to siblings.  (I like what Prince does in your example.)  I would like a 
(pseudo-)element E to run into the most distant suitable block/list-item 
that is not preceded by an unsuitable (pseudo-)element nor by a suitable 
(pseudo-)element with non-zero border box area.  More formally, to run 
into the unique block B such that

(i) B is an in-flow element which is specified to have display:block or 
display:list-item, and
(ii) B generates the nearest ancestor principal block box of the closest 
subsequent (possibly empty) line box in the same block formatting 
context as E, and
(iii) no box with specified display other than 'block' or 'list-item' 
and used display other than 'none' comes between E and B, and
(iv) no box with specified display:block or display:list-item and with 
used display other than 'none' and with non-zero border box area comes 
between E and B

if B exists, or otherwise into the nearest suitable sibling (if it 
exists). [Where "closest" and "comes between" are used in the context of 
a depth-first document tree traversal.]

Note that (iv) relates to my earlier point about empty paragraphs.


Issue V:  I agree that out-of-flow boxes should be ignored.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 21 August 2009 17:35:01 UTC