- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 27 Feb 2009 13:33:19 -0600
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Giovanni Campagna <scampa.giovanni@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
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.
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.
dave
(hyatt@apple.com)
Received on Friday, 27 February 2009 19:34:01 UTC