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

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:
>>>> Hello,
>>>>
>>>> I am not sure I understand this quote from the spec:
>>>>
>>>> "
>>>> 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...
>>>>
>>>> Can someone show me an example or a test where this happens?
>>>>
>>>> I fail to see how this statement can be demonstrated or verified
>>>
>>> Sure it can!  And you're doing so in your test case.
>>>
>>>> and why it should be correct to begin with.
>>>
>>> Using the margin box instead of line-height to determine the
>>> contribution that an atomic inline-level object such as an inline-block
>>> makes to the height of the line box
>>
>> Right here: how do you verify the height value of such line box in the
>> test given? Say with browser webpage debuggers like Firefox DOM
>> inspector
>> or Chrome Web inspector or Opera Dragonfly?
>
> I don't believe it's possible to query linebox height directly.
>
>> [...]because the inner div inside div#div2 (div#div2 > div ) is the only
>> inline
>> element contributing to the height of the line box.
>
> Yes, querying the auto-height block container which contains the sole
> linebox (which contains a sole inline-block) seems like a good strategy.
>
>> [Addendum: I now think used line box height value is not retrievable
>> anyway, is not accessible. Computed line box height is but not used line
>> box height.]
>
> I don't know whether or not inspectors provide used style info in
> addition to computed style info.


As far as I know, mainstream browser webpage debuggers and inspectors
(Firefox DOM inspector, Chrome web inspector, Opera DragonFly, IE
developer tools, Konqueror DOMTreeviewer) do not provide used style
info... although/except one, I believe, did: Hv3 TKHTML alpha 16 .

>
>>>> The computed value of line-height of the inner div inside
>>>> div#div2 is reported to be 0px in Firefox 16.0's DOM inspector, in
>>>> Opera
>>>> 12.02's DragonFly and in Chrome 22.0.1229.92's web inspector.
>>>
>>> Indeed.
>>>
>>> That's precisely what the spec is saying; it's not the line-height
>>> value
>>> on an inline-block which determines its contribution to the height of
>>> the line box in which it sits.  Rather, it's the margin area height.
>>> Hence the line box is 100px high in your test case.
>
> Sorry, I meant 1in, not 100px.
>
>> Okay where do you read or see this? I can see the blue square area but
>> how
>> does the blue square area relates to the used height of the line box
>> given
>> or created or generated by div#div2 ?
>>
>>    48px : margin-top of inline-block
>>   +
>>    48px : margin-bottom of inline-block
>>   +
>>     4px : descent area (usual vertical
>>           area below baseline when font is 16px or so)
>>   ======
>>   100px
>
> Yeah, ignore my 100px.  I meant 1in / 96px.


If you remove 'line-height: 0' (at line 12) in the test

http://test.csswg.org/suites/css2.1/20110323/html4/inline-block-non-replaced-height-002.htm

, then it will be 100px   :)


> 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;
descent area is glyph's descender height (distance between bottommost
point of glyph and baseline).
http://en.wikipedia.org/wiki/Descender

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.
E.g.:

http://www.maxdesign.com.au/articles/css-line-height/

and view from slide 81. 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.

Disclaimer: there are some slides in that slide presentation which are not
accurate or not irreproachable in my opinion: eg slide 71 is not accurate.



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

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

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 Friday, 12 October 2012 21:52:48 UTC