Re: [csswg-drafts] [css2][css-inline] Definition of line-height calculations contradicts itself

Hi fantasai!  It's been a long time; hope you're doing great.

I think you've hit upon an issue which we've discussed in detail in 
the past but which has ended up being edited into the spec in a 
contradictory way.

>From what I gather from conversations in 2010/11 with Bert, the 
"height" of an non-replaced inline box is intended to be exactly the 
value of `line-height`, which means that your proposed fix in favour 
of the second clause in the spec sentence you quoted is the right way 
to go.

Your analysis of the A,D stuff is correct, and I think it was an 
oversight that the possibility of a bounding box of the glyphs+leading
 being taller than the value of `line-height` was not spotted by any 
of use when Bert made a final set of edits to this section of the spec
 (to kill of a whole bunch of issues that had been raised).  I can see
 how the mistake could have slipped in, because, as so often, there 
was a complex history to this box height stuff, as I explain below.

Originally the spec was very unclear about the height of an inline 
box, and we aimed to make it more concrete.  But the reality was and 
is that the height is _not_ the content area height.  I described a 
mental model of the situation using "guide boxes" (rectangles, really)
 which are exactly line-height high and which are vertically centred 
within the content area box of the inline box.  The distance from the 
top of the guide box to the top of the content area box (which may be 
negative) is interpreted has the half-leading - and hence half-leading
 becomes a property of the inline box rather than of the individual 
glyphs, although in any case the leading and half-leading is not a 
relevant concept in CSS; we define it simply because it supposedly 
makes the model easier to visualize because it's a concept that people
 are familiar with.  When calculating the vertical extents of the line
 box, we only consider the relative positions of the guide boxes; the 
content area box (and indeed border box and margin box) of the inline 
boxes is totally ignored.  You rather liked this mental model, I 
believe, and were intrigued by a rendering example which is very hard 
to make sense of without guide boxes but which makes total sense with 
them.  See the last two sections of the following e-mails (and ignore 
the rest of the e-mails!): 
https://lists.w3.org/Archives/Public/www-style/2010Jul/0535.html
https://lists.w3.org/Archives/Public/www-style/2010Aug/0012.html

In the spec, by the end, we didn't explicitly describe the model in 
terms of "guide boxes" although it has always been the underlying 
concept and we did end up with it being a bit more transparent (which 
is why the spec now explicitly talks about inline boxes which are 
line-height "high" - and again, note that this "height" is not what we
 usually think of as height, namely content-area height).

But before that happened, some relevant other edits happened, which 
have lead to the unforeseen contradiction that we're discussing.  
Firstly, with a view to resolving other editorial issues in 10.8 (of 
which there were many, and tricky), Bert proposed a change which meant
 that the inline box could be more than line-height "high", in order 
to accommodate the fact that not only could it contain contains glyphs
 from fonts with different metrics, but also contain other inline 
boxes from child elements.  I was wary about the proposed change, 
because I felt that it was a change from the existing logic, and I 
asked for evidence of browser interop for it: 
https://lists.w3.org/Archives/Public/www-style/2010Oct/0106.html

However, it later transpired that having inline box height depending 
on other inline boxes from child elements would contradict other 
changes which Bert wanted to make, as I pointed out in 
https://lists.w3.org/Archives/Public/www-style/2011Mar/0139.html .  So
 (happily, from my perspective) it was decided to go back to having 
the inline box height _"not be dependent on child elements and thus 
guaranteed to be 'line-height'. We needed that for issue 153, which 
requires a box of that height for 'vertical-align' to work on"_ 
[Bert].  See 
https://lists.w3.org/Archives/Public/www-style/2011Mar/0635.html .  
And indeed a box of that height _is_ required (it's the "guide" box) 
so the decision was a good one.  The problem is that the conclusion - 
"thus guaranteed to be 'line-height'" - is actually false, as you've 
hit upon; unfortunately, the earlier observation that the inline box 
might be taller than `line-height` due to glyphs from fonts with 
different metrics was forgotten.  To fix the issue, really we need to 
be more explicit about the guide box model (and, in particular, move 
away from the idea of glyph-specific leading).

-- 
GitHub Notification of comment by antonprowse
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/391#issuecomment-252964080 
using your GitHub account

Received on Tuesday, 11 October 2016 16:08:52 UTC