Re: Clarification needed for inline boxes containing block boxes

2009/2/27 Andrew Fedoniouk <news@terrainformatica.com>:
> 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.

This is not always true, ie. there are other differences between
blocks and inline-blocks, for example inline-blocks are BFC (flow
roots), while blocks are not generally. Also, you may have fixed width
for an inline-block, and still want it in the middle of the line
(something that you cannot have with block, even if you invent a new
keyword for width called shrink-to-fit).

>>> 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.
Vertical margins on inline box are not relevant, because only
line-height is used to compute the block-progression dimension of the
line box (css21 sect 10.6.1). So only the margin on inline-block is
used, which is very similar to collapsing margins of inline and
inline-block (as long as the margin set on inline-block is greater
than the other).

> I am not sure I understand to what in my message this "not true at all"
> should be applied.
He correctly meant that display:block is not the same as
display:inline-block;width:100%;

> 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

This is not a CSS problem, rather a language problem. If you feel that
this issue should solved, mail at public-html@w3.org

> 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.

Don't forget of XML: in that case you have no way to block the <div>
inside the <span>.

> 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.

In Opera, Firefox 3 and Safari, I get the same results when using
<div> instead of <span> (or HTML instead of XML). The fact that all
browser give different results is the origin of this issue, and what
we're trying to solve, but at least they're all consistent with
themselves.

> 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?
Sorry but they don't (at least Presto, WebKit and Gecko don't). Try
using Firebug, Dragonfly or WebInspector to look at the DOM.

>
>>
>> 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.

Again, this is not a viable solution at the CSS level. And doesn't
solve DOM manipulation, explicit display setting and XML cases.

>>
>> dave
>> (hyatt@apple.com)
>>
>>
> --
> Andrew Fedoniouk.
>
> http://terrainformatica.com
>
>
>
>

Giovanni

Received on Saturday, 28 February 2009 17:17:01 UTC