Re: Clarification needed for inline boxes containing block boxes

David Hyatt wrote:
> On Feb 27, 2009, at 1:24 PM, Andrew Fedoniouk wrote:
>
>>
>> display-model (that is hypothetical attribute that used to be in 
>> drafts at some point[1])
>> has an absolute priority in this case and so all its immediate 
>> children with
>> display:block will have computed value of the display equal to 
>> 'inline-block'.
>>
>> This is pretty old problem actually. AFAIR Gecko and IE were using 
>> this way of treating display:blocks
>> inside inlines from the very beginning.
>>
>> In general 'inline-block' value of the 'display' is superfluous. The 
>> only useful case
>> for the 'inline-block' is when it is used for determination of actual 
>> value of "width:auto" of such block.
>> In case of display:inline-block it gets resolved to width: 
>> max-intrinsic ((c) D. Baron)
>> and in case of  display:block inside spans it gets resolved to the 
>> width: 100%-of-nearest
>> block-container-width.
>>
>> For the observer this means that pure <div> inside <span> shall take 
>> single line box as
>> if that div was styled as {display:inline-block; width:100%}.
>>
>
> That's not true at all.  Margins still collapse through contiguous 
> blocks, even across the empty inline boundaries.  An inline-block 
> would not do this.  Inline blocks do not collapse margins with inline 
> blocks on previous or subsequent lines, nor do they collapse with 
> margins of contiguous blocks above and below all of their containing 
> block's lines.  That is a requirement for Web compatibility here.
I am not sure I understand to what in my message this "not true at all" 
should be applied.

First of all:
   <span>aaa<div>bbb</div>ccc</span>
is not a valid markup at all. In the same way as
   <p>aaa<div>bbb</div>ccc</p>.
Not for HTML4 nor for HTML5.

So theoretically while parsing you should get either:
a)
<span>aaa</span>
<div>bbb</div>
<span>ccc</span>

or just
b)
<span>aaa</span>
<div>bbb</div>
ccc

That will give proper margin collapsing, etc.

But I am speaking about the case:

c) <span>aaa<span style="display:block">bbb</span>ccc</span>
or
d) <span>aaa<div>bbb</div>ccc</span>
when this div gets into the DOM through the dom manipulation methods.

These two cases: <div>bbb</div> and <span style="display:block">bbb</span>
shall be handled exactly in the same way. But for some unknown reasons
they produce completely different results in Gecko, WebKit and Trident.

Again for the external observer (I mean visually) all of them do 
something like this:
  <span>aaa</span>
  <div>bbb</div>
  ccc
on parsing. Otherwise I cannot explain difference between c) and d) cases
rendering in mentioned engines. Any idea of what is going on under the 
hood there?

>
> This is not a theoretical situation by the way.  Blocks inside inlines 
> occur all the time in the real-world Web, so there is a large set of 
> behaviors here that cannot be changed.
I know that. All cases what I've seen (not too many to be honest)
can be solved on parsing level by using scenario b) while parsing.

>
> dave
> (hyatt@apple.com)
>
>
--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 27 February 2009 20:59:33 UTC