Re: [CSS21] Question on height of inline-block (possible error in § 10.6.6)

On 12/10/2012 22:52, "Gérard Talbot" wrote:
> Le Ven 12 octobre 2012 4:46, Anton Prowse a écrit :
>> On 11/10/2012 19:51, "Gérard Talbot" wrote:
>>> Le Jeu 11 octobre 2012 1:33, Anton Prowse a écrit :
>>>> On 11/10/2012 05:29, "Gérard Talbot" wrote:
>>>>> "
>>>>> For 'inline-block' elements, the margin box is used when calculating
>>>>> the
>>>>> height of the line box.
>>>>> "
>>>>> http://www.w3.org/TR/CSS21/visudet.html#block-root-margin
>>>>>
>>>>> It does not make sense in my mind...

>> Now, there /is/ a descent
>> area somewhere... but there's nothing in it, so it's invisible ;-).  In
>> fact, the descent area is precisely what bleeds out of the bottom of the
>> line box, as follows.
>
> Euh... no. In my mind, descent area is not bottom-half-leading here

It is when the line box bottom edge coincides with the baseline, as in 
your test case.  To be precise, the bottom (and top) half leading is 
negative but has the same magnitude as the descender space.

> Line box usually includes descent area (descent area being the bottom part
> of glyphs like gjypq). Descent area does not bleed out of the bottom of
> the line box unless the line box has been set smaller than font-size.

No, it's not that simple, as your test case shows. (It's typically only 
that simple when the line box only contains atomic inline boxes whose 
glyphs all come from the same font as the strut. Whereas your test case 
contains a large inline block.)

> http://www.maxdesign.com.au/articles/css-line-height/
>
> and view from slide 81.

[That's possibly the most accurate author-targeted overview of the 
inline formatting model I've ever come across.  Props to its author!]

> In slide 83, we actually see that the line box
> height is smaller than font size and we can clearly see that "g" and "j"
> glyph descender (and also acute accent at top of "A" glyph) bleed out of
> line box.

Yes.  (Though ironically that's the only slide that I take real 
technical issue with, since I have no idea what the author means by "The 
half leading collapses together to form the inline box height", and the 
visualization of the half leading as being inside the line box is (to 
me) misleading.  I would have drawn it as stretching between the inline 
box content edge and the line box edge, together with something to 
indicate the fact that it's negative.)

>>>> In fact, I like to think of there being a
>>>> "guide box" that's line-height high that is a vertically-centred
>>>> overlay
>>>> of the inline box.  It helps me visualize how the line box extents are
>>>> determined - they depend on the guide boxes, and hence they do not
>>>> directly depend on the contents of the box.)
>>>
>>> Your guide box concept would be great if it had a schematic
>>> representation
>>> or a tutorial somehow. It's difficult to imagine what it is without an
>>> article or webpage explaining it along with judicious illustrations.
>>
>> Yeah, I should probably make a webpage with illustrations of this.
>>
>> Let me try to draw your example:
>>
>>  ->       ,=================.
>>           |                 |
>>           |                 |
>>           |  margin area of |
>>      ,==. |  inline-block   |
>>      |  | |                 |
>>      |  | |                 |
>>  ->  | *| |                 |
>>  ->  |--| `================='
>>      |  |
>>      `=='
>>
>> There's an imaginary zero-width strut, baseline-aligned with the
>> baseline (ie bottom margin edge) of the inline-block.  You can see the
>> descender space hanging below the baseline.  But to determine the
>> linebox extents, you need to use the zero-height guide box of the strut
>> (marked with a '*') and the top/bottom margin edges of the inline block.
>>    Hence the line box stretches between the uppermost arrow and the
>> lowermost arrow that I've marked in the diagram.  The blue block
>> container snugly wraps the line box.  Hence the descender space bleeds
>> out.  Of course, that space is both invisible and undetectable.
>
>
> I'm sorry, Anton. Ascii drawing is not ideal here.

Sorry, that's the only thing I'm likely to offer right now ;-)

> Thanks for your emails and assistance here. I appreciate the time you
> spent on my question and comments.

You're welcome :-)

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Saturday, 13 October 2012 08:46:50 UTC