Re: [CSS21] Issues with inline formatting model (particularly 10.8)

On 07/31/2010 08:50 AM, Anton Prowse wrote:
> Anton Prowse wrote:
>
> Relevant editorial issues
> -------------------------
>
> These issues assume that the spec wishes to commit to the idea of
> inline-level box height being defined (and thus determined by the
> 'line-height' property) and used for line box height calculation.
>
>
> Issue 13, revisited:
>
>> 10.8 (Line height calculations):[1]
>>
>> # [...]. The height of a line box is determined as follows:
>> # 1. The height of each inline box in the line box is calculated (see
>> # "Calculating heights and margins" and the 'line-height' property).
>
> The reference to the "Calculating heights and margins" part of the spec
> should be removed, since that section concerns itself only with /content
> area/ height.

I disagree with this edit. Section 10.6 is not relevant for inline
boxes, but it is necessary to consult it for e.g. inline-blocks.
Note s/each inline box/each inline-level box/ from issue 120.

> Issue 14: not relevant
>
> To *ensure* that the "Calculating heights and margins" part of the spec
> concerns itself only with content area height and doesn't stray into
> tangential matters, the following sentences should be moved from that
> section down to 10.8.
>
> 10.6.1 (Inline, non-replaced elements):
> # The vertical padding, border and margin of an inline, non-replaced
> # box start at the top and bottom of the content area, not the
> # 'line-height'. But only the 'line-height' is used when calculating
> # the height of the line box.
>
> (Also cf. Issue 3b [2,3].)
>
> 10.6.2 (replaced inline/inline-block elements):
> # For 'inline' and 'inline-block' elements, the margin box is used
> # when calculating the height of the line box.
>
> 10.6.6 (non-replaced inline-block elements):
> # For 'inline-block' elements, the margin box is used when calculating
> # the height of the line box.

I don't see these edits as necessary.

> Issue 15:
>
> 10.6.2 (replaced inline/inline-block elements):
> # For 'inline' and 'inline-block' elements, the margin box is used
> # when calculating the height of the line box.
>
> 10.6.6 (non-replaced inline-block elements):
> # For 'inline-block' elements, the margin box is used when calculating
> # the height of the line box.
>
> In both these cases,
> s/line box/inline(-level) box/
> since there's no need to be indirect here. (We know the line box height
> depends on the inline(-level) box height.)

These edits are wrong. The margin box is not used for calculating the
height of the inline box. They are used for calculating the height of
the line box.

> Issue 16:
>
> 10.8.1 says:
> # On a block-level, table-cell, table-caption or inline-block element
> # whose content is composed of inline-level elements, 'line-height'
> # specifies the minimal height of line boxes within the element. [...]
>
> # On an inline-level element, 'line-height' specifies the height that
> # is used in the calculation of the line box height (except for inline
> # replaced elements, where the height of the box is given by the
> # 'height' property).
>
> I don't follow the inline-block bit at all: does "whose content is
> composed of inline-level elements" qualify inline-block, or all the
> element types listed? Why is this case noteworthy? What if the content
> isn't composed like that? Also, shouldn't inline-table be mentioned
> here, or should we really not be highlighting inline-block and
> inline-table at all and instead talk about inline-level block containers
> (see [5])? See also [6; Issue 2].

This sentences is talking about block containers that contain inline-level
content. (See issue 120.) It doesn't apply to block containers that
contain only block-level content, because they do not have line boxes.

> On an inline-block (and inline-table), does 'line-height' apply to the
> "inside" or the "outside", or both? That is, does it determine the
> height of the box or the minimum height of line boxes inside the box, or
> both?

See issue 120. If it's not clear there, then we can work on it there.
'line-height' is only used in calculating the line box height when
we're dealing with inline elements specifically, not inline-level
elements in general.

> Issue 17:
>
> There appears to be a contradiction between 10.8.1:
>
> # On an inline-level element, 'line-height' specifies the height that
> # is used in the calculation of the line box height (except for inline
> # replaced elements, where the height of the box is given by the
> # 'height' property).
>
> and 10.6.2 / 10.6.6:
> # For 'inline' [replaced] and 'inline-block' [replaced] elements, the
> # margin box is used when calculating the height of the line box.
>
> # For 'inline-block' [non-replaced] elements, the margin box is used
> # when calculating the height of the line box.
>
> For inline replaced elements, is it the 'height' property or the margin
> box which determines the height of the inline-level box?
>
> For inline-block elements, is it the 'line-height' property or the
> margin box which determines the height of the inline-level box?
>
> However, this issue might become clearer once some light has been shed
> on Issue 16 above.

Good catch. That parenthetical should be removed, and the sentence
should start "On a non-replaced inline element".

> Issue 18:
>
> # User agents center glyphs vertically in an inline box, adding
> # half-leading on the top and bottom. [...]
>
> # When the 'line-height' value is less than the content height, the
> # final inline box height will be less than the font size and the
> # rendered glyphs will "bleed" outside the box. [...]
>
> Assuming that leading is the mechanism which determines where the
> vertical extents of the inline-level box lie relative to the content
> area (meaning that the vertical center of the inline-level box is
> incident with the vertical center of the content area; see also [7]),
> then leading may be negative. This is implied in the text, but I think
> it should be mentioned explicitly, perhaps as a note. (cf. 9.5.2:
> clearance).

I don't see a problem with adding a note about negative leading here.

> Issue 19:
>
> 10.6.1:
> # The height of the content area should be based on the font, but this
> # specification does not specify how.
>
> For added emphasis, I'd like to see a note in 10.6.1 that the content
> area height of an inline box doesn't depend on its descendant boxes
> (neither in terms of their glyphs, font or line-height) but only on its
> own glyphs and font.(*) This is a potential gotcha.
>
> (*) Here, for simplicity, I'm ignoring inline-level content other than
> text.

This is a good idea.

> Alternative construction for line box height calculation
> --------------------------------------------------------
>
> Ch.10 wants to define the "height" of an inline box to be something
> unrelated to its box model. We've seen that at least this doesn't
> contradict anything elsewhere in the spec.
>
> Still, I'm not sure that this is the clearest construction to use. This
> part of the spec is notoriously difficult for people to understand, but
> my feeling now is that this is less to do with conceptual difficulty and
> more to do with a poor choice of construction (aided by numerous
> editorial bugs and several technical issues). Under the current model,
> even the content area of an inline box can "bleed out" of its own
> "boundary", which is quite some gotcha for those without detailed
> knowledge of this section!
>
> If I were writing a guide to the inline formatting model, I would use
> the following construction for 10.8.
>
> | Vertical alignment of inline boxes and determination of line box
> | height is performed, not using the inline boxes themselves, but
> | rather using a "guide box" to represent each inline box. The height
> | of each guide box is determined only by the value of the line-height
> | property on the inline box. Leading is realized as spacing applied
> | to the content box to center the inline box's content area within
> | its guide box; the guide box may be shorter than the content area
> | and so leading may be negative. (Cf. [2].)
>
> It differs from the existing construction only in the provision of extra
> guide boxes instead of reliance in an unintuitive definition of inline
> box height, but the advantage is that these tangible boxes cannot be
> confused with glyph boxes or box model areas, which makes line height
> calculation and vertical alignment considerably easier to grasp. (It
> also means that there's no need to attempt to define the "height" of an
> inline box, which is consistent with the perhaps intentional vagueness
> elsewhere in the spec.)

This makes sense to me. I agree that the concept of the height of an
inline box should be decoupled from the line-height concept used in
calculating the height of a line box; it's confusing to have the
"height" of a box have no relation to the height of its content,
padding, or margin boxes.

> Motivation behind the current inline formatting model
> -----------------------------------------------------
>
> 'line-height' property:
> # Generally, when there is only one value of 'line-height' for all
> # inline boxes in a paragraph (and no tall images), the above will
> # ensure that baselines of successive lines are exactly 'line-height'
> # apart. This is important when columns of text in different fonts
> # have to be aligned, for example in a table.
>
> Interestingly, this result might /not/ be achieved if the vertical
> alignment depends on the font baseline and baseline is in a different
> "position" in the different fonts, or if the method used for calculating
> the height of the content area in 10.6.1 is not based on the em box.
> But the general desire for baselines of successive lines to be exactly
> 'line-height' apart in the most simple situations is sound, and
> achievable with the existing model.
>
> If 'line-height' were not to apply to inline elements, the model would
> produce very intuitive results since there could be no bleeding of
> glyphs. But, assuming that bleeding is desirable, the existing model
> is merely one of various possible ways to achieve it. Yet the chosen
> model has some peculiar features. One interesting fact, for example, is
> that the bottom half of the content area can never bleed out of the top
> of the line box in which it sits, and the top half can never bleed out
> of the bottom; we observe this in the follow test case which is pretty
> much the quintessential test case for the model and routinely results in
> bafflement for those who lack a deep understanding of how it works.
>
> <div style="line-height:20px; width:280px">
> text text text text text text text text text text text text
> <span style="line-height:inherit; font-size:140px">text</span>
> text text text text text text text text text text text text
> </div>
>
> Why does the line box containing the span increase but still allow a
> seemingly rather small amount of the tops of the span's glyphs to bleed
> out? It's only obvious when you know how, and I don't think anyone
> could call it intuitive!

That's a very interesting testcase.

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22line-height%3A%2020px%3B%20width%3A280px%3B%20margin-top%3A%204em%3B%22%3E%0A%3Cspan%20style%3D%22border%3A%20dotted%201px%3B%20color%3A%20gray%22%3E%0Atext%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%0A%3Cspan%20style%3D%22line-height%3A%2020px%3B%20border%3A%20solid%3B%20font-size%3A140px%3B%20color%3A%20black%22%3Etext%3C%2Fspan%3E%0Atext%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%20text%0A%3C%2Fspan%3E%3C%2Fdiv%3E

~fantasai

Received on Monday, 2 August 2010 18:37:16 UTC