W3C home > Mailing lists > Public > www-style@w3.org > March 1999

Line height, images, vert. alignment, and so on

From: Eric A. Meyer <emeyer@sr71.LIT.CWRU.Edu>
Date: Sat, 27 Mar 1999 16:24:51 -0500
Message-Id: <v04011700b322fcd0b708@[]>
To: www-style@w3.org
Hey all,

   So I've been combing through the Text Properties section of CSS1 in
conjunction with a project of mine, and I've come across two things which
really bug me.  Besides which, one of them impacts directly on the Test
Suite.  Any clarifications or insights would be very welcome.

   So far as I can tell, the height of a line of text is determined by
whatever appears on that line.  For example, in CSS2, it says that:

    "When an element contains text that is rendered in more than one font,
user agents should determine the 'line-height' value according to the largest
font size." (CSS2:10.8.1)

Fine, I can accept that.  This implies to me, then, that if an inline image
(or other replaced element) is part of a line, then the 'line-height' of a
line needs to be increased to match the tallest element on the line.  In
re-reading CSS1, I didn't see anything to contradict this position.  On the
contrary, I found material to support it:

   "Replaced elements (e.g. images) on the line can make the line-box bigger,
if the top of the replaced element... is above the tallest text section, or
if the bottom is below the lowest." (CSS1:4.4)

   Is it the case that making the line-box bigger also increases the
'line-height'?  Because if so, the test for percentage values on
'vertical-align' in the Test Suite is WAY wrong and need to be errata'ed as
soon as possible.  If not, why not? What special magic do inline replaced
elements have that cause them to force open enough vertical space for them to
appear on a line, but still not increase the 'line-height' in the way the
different fonts do, as described in CSS2?

'top' and 'bottom'
   Most of us are probably familiar with the famous "unsolvable loop" problem
which arises in conjunction with the use of 'top' and 'bottom' fr
'vertical-align'.  It's explained in some detail on p.156 of Lie & Bos, and
in brief (for those who don't have the book), it goes something like this:

   Set a tall image (#1) to be aligned 'bottom' and a short image (#2) to be
aligned 'top'.  #1 is aligned with the bottom of #2, and then #2 is aligned
with the top of #1.  However, this means that #1 is no longer aligned with
the bottom of #2, so it's realigned; then #2 has to be re-aligned to the top
of #1, and ping pong, there's your loop.

However, all of this appears to hinge on the assumption that any given
element must be aligned with the top (or bottom) of the highest (or lowest)
element in the line OTHER THAN ITSELF.  This assumption is explicitly stated
in Lie & Bos, where it says:

   "...but 1 is not aligned with the top of the tallest thing (besides
itself)..." (Lie&Bos:p.156)

   This leads me to ask: so what?  I can't find anything in CSS which says
that values of 'vertical-align' force an element to be aligned to everything
other than itself.  To me, this seems a little weird-- why would an element
ignore itself in determining what's highest or lowest in a line?  Nothing
else does, including, so far as I'm aware, the part of the UA which
calculates the 'line-height' in the first place.
   If this assumption is discarded, then the the situation described above
would be resolved as follows:

   Set a tall image (#1) to be aligned 'bottom' and a short image (#2) to be
aligned 'top'.  #1 is aligned with the bottom of itself (therefore not
moving), and then #2 is aligned with the top of #1.  Since the bottom of #1
is aligned with the bottom of the lowest things on the line (in other words,
itself), it's fine.  Since the top of #2 is aligned with the top of the
tallest thing on the line (the top of #1), it's fine.  Everyone's fine.

   Did I miss something really crucial, or is there a weird unstated
assumption built into CSS which we could all agree to drop, thereby solving
this situation outright?


Eric A. Meyer  #  eam3@po.cwru.edu  #  http://www.cwru.edu/home/eam3.html
Received on Saturday, 27 March 1999 16:19:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:49 UTC