Display: run-in

Hi,
The 'run-in' 'display' value seems somewhat unnecessary and it seems to me like it
should have been dropped for CSS 2.1. If it isen't, it may need some improvements in 
its description for step 2 at 
http://www.w3.org/TR/CSS21/visuren.html#run-in (or in a future version).

I belive it should be defined to not "run into" a box that generates a new block
formatting context. That is, it dosen't make sense to me for a 'run-in' to become the
first inline in a table-cell following the 'run-in', and it probably does not for the
others either. When comparing the concept to how list-item-markers (in 
implementations if not in the rec) are positioned versus the first line of the first inline
context of the principal box of the list-item, the above seems a sensible restriction. 

Further, i think the following sibling block box description isen't good enough to cover
cases such as:
<h3 style="display: run-in">Run-in heading</h3>
<div class="chapter">
  <p class="section">First line...
Should the 'run-in' "run into" the chapter or section? I think it should run into section
rather than chapter if possible, and probably become a block otherwise rather than 
running into chapter like the rec currently states. It is also possible that this affects the
margin-collapse sentence: "The top margin of an in-flow block-level element is 
adjoining to its first in-flow block-level child's top margin if the element has no top 
border, no top padding, and the child has no clearance.". It probably needs to add 
", no run-in" to the "if the element has no top border, no top padding" part.

Finally, when the following sibling is removed from the flow, eg absolutly positioned or
floating, shouldn't the 'run-in' try to "run into" the next sibling, similar to how
margins can be adjacent and collapse in such cases?

I would also be interested to know which UAs (other than Opera) try to support the
value.

 /Staffan

Received on Sunday, 6 February 2005 16:05:42 UTC