W3C home > Mailing lists > Public > www-style@w3.org > February 2009

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

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 27 Feb 2009 13:09:29 -0800
Message-ID: <49A85689.7050503@terrainformatica.com>
To: David Hyatt <hyatt@apple.com>
CC: Giovanni Campagna <scampa.giovanni@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
Please discard this message:

Beg my pardon for the noise.

Andrew Fedoniouk.


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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:24 UTC