[Recall] Re: Clarification needed for inline boxes containing block boxes

Please discard this message:

Beg my pardon for the noise.

--
Andrew Fedoniouk.

http://terrainfromatica.com


Andrew Fedoniouk wrote:
> 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 21:10:11 UTC