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

fantasai wrote:
> 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.

[That should have been:

"(and thus determined by the 'line-height' property, or possibly by
other means in the case of inline boxes generated by inline-block and
inline-table elements)"

Sorry for any confusion.  Anyhow, we're gradually clearing up what those
other means are.]


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

The current spec has tiny snippets of info in 10.6.1, 10.6.2 and 10.6.6
which describe the "height" of inline-level elements for the purpose of
calculating the height of the line box, in addition to the descriptions
of how to calculate the height of their content areas.

Issues 13 and 14, taken together, are saying that instead of 10.8
pointing to 10.6 for those snippets, it would be preferable to move
those snippets to 10.8 (where they are more relevant anyway), which does
away with the need to reference 10.6.

If I'm not misunderstanding you, you're rejecting this proposal but
without specifying why.


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

But the "height" of the inline box is precisely *what* (helps to)
determine the height of the line box, according to the current spec.

I don't like the way the spec uses "height" in this way, hence my
presentation of an alternative construction in my original post.  But it
/does/ use it in this way (not in 10.6.*, but in 10.8).

Issue 15 says that if it's going to continue using "height" in this way,
then 10.6.* ought to change to match it.

The edits are helpful rather than essential.  I don't believe them to
be wrong; however, they might be improved as follows:

s/the margin box is used when calculating the height of the line box/the
margin area height gives the height of the inline-level box/

(since preserving the word "calculating" in the proposed text is a bit odd).


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

Great, thanks.  So the phrase qualifies all the element types listed.
With this now clarified, my sentence about inline-table is not relevant.


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

OK.


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

Sure.  For inline-blocks, for example, we use their "height" instead
(according to 10.8).  Unfortunately, 10.8 doesn't define the "height" of
an inline-block (notwithstanding the contradiction described in Issue
17, below); and 10.6.2 and 10.6.6 don't mention "height" either (only
content area height), but they do refer to a quantity that is "used when
calculating the height of the line box" – which is precisely the
unspoken definition of "height" in 10.8.  See my response to Issue 15,
above.


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

So for inline-level replaced elements, the margin box is used when
calculating the height of the line box.  In other words, the "height" is
the margin area height.

For inline-level non-replaced non–inline-block elements, 'line-height'
specifies the height that is used in the calculation of the line box
height.  In other words, the "height" is the 'line-height'.

But what about non-replaced inline-blocks?  The contradiction still
exists for those.  This will need resolving as part of Issue #120.  (See
my middle response to Issue 16 above.)


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

Great!


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

Cool.


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

Great; I'm glad you agree at a conceptual level!


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

Yep.  Now imagine those guide boxes, and it all becomes obvious ;-)


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

Received on Monday, 2 August 2010 21:52:00 UTC