- From: Felix Breuer <felix@fbreuer.de>
- Date: Sun, 12 Oct 2003 01:55:01 +0200
- To: www-style@w3.org
On 17:12 Sat 11 Oct , fantasai wrote: > > Felix Breuer wrote: > > > >Looking at both "CSS 2.1" and "CSS 3: the box model" I could not find out > >how the following is supposed to be rendered: > > > ><div class="block"> > > <div class="runin">Is this supposed</div> > > <div class="inline">to run in?</div> > ></div> > ... > > Might want to take a look at > http://lists.w3.org/Archives/Public/www-style/2000May/0004.html > > While we're on the topic, though, I'd like to bring up > http://lists.w3.org/Archives/Public/www-style/2000May/0010.html > as well. These two mails basically say that a run-in element followed by an inline element are rendered as two blocks (on two lines). However, the CSS3 Box draft refers to "Ian's tests" [1] and there it says <div class="test"> <span class="h block"> This is a block on its own. </span> <span class="g run-in"> This text should </span> <span class="g inline"> run-in to this one. </span> <!-- ...because the inline is wrapped in an anonymous block box. --> </div> Am I right in concluding that the intended sequence of events is 1) The user agent encounters the first element and determines its display-role. Since this is "block" all "inline" siblings are wrapped in anonymous block boxes. This wrapping takes place immediately. 1a) The user agent checks whether the second element has to be wrapped. Since it is a "run-in" element it is not wrapped, even though it has not been determined whether the "run-in" element will become a "block" or an "inline" element. 1b) The user agent wraps the third element because this is clearly inline. 2) The user agent encounters the run-in element, notices that a block box follows and thus adds the run-in as an inline box to the anonymous block box. .. Hm, this algorithm still looks funny to me. Does it reflect the intended behaviour? Thanks, Felix Breuer
Received on Saturday, 11 October 2003 19:57:45 UTC