W3C home > Mailing lists > Public > www-style@w3.org > October 2012

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

From: Gérard Talbot <www-style@gtalbot.org>
Date: Sat, 13 Oct 2012 21:38:19 -0400
Message-ID: <c9eddd1ee767268c00acb5b9da69875e.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Anton Prowse" <prowse@moonhenge.net>
Cc: "Public W3C www-style mailing list" <www-style@w3.org>

Le Sam 13 octobre 2012 4:46, Anton Prowse a écrit :
> 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.

Need to recheck this... as soon as I can fetch the url of that test

>
>> 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!]


It is pretty accurate and well done considering the inherent difficulties
of that tutorial but there are some inaccuracies. (Identification of some
areas and rectangles are difficult to figure out sometimes; color of
arrows would help but it seems to be red everywhere.)

eg: in slide 71, we can notice vertical separation between the 2 line
boxes while CSS2.1 is formally stating:
"Line boxes are stacked with no vertical separation"
http://www.w3.org/TR/CSS21/visuren.html#inline-formatting


>
>> 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 ;-)

One day, you could create your own slide presentation on all this, where
your guide box concept would be illustrated, demonstrated...

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Sunday, 14 October 2012 01:38:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT