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

Re: line-box-contain question

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 18 Mar 2011 11:20:41 -0700
To: David Hyatt <hyatt@apple.com>
Cc: www-style CSS <www-style@w3.org>
Message-ID: <20110318182041.GA10971@pickering.dbaron.org>
On Friday 2011-03-18 12:54 -0500, David Hyatt wrote:
> http://dev.w3.org/csswg/css3-linebox/#LineStacking
> For the 'font' value, the text says:
> "The block progression dimension of all non-replaced inline boxes..."
> And then later on the text implies that line-box-contain:font
> replaced is the backwards-compatible HTML value (more or less).
> Shouldn't that be "The extended block progression dimension..."?
> It doesn't seem correct that 'font' value excludes the
> half-leading.  That would mean that "font replaced" completely
> ignores line-height.  Is that really intentional?  Shouldn't
> 'font' be equivalent to 'inline' and include the half-leading, and
> be identical other than the restriction of having to have an
> immediate non-empty text child?
> That's how the quirks mode code looks in WebKit, so I thought I'd
> double check.

Hmmm.  The behavior in which the half-leading is ignored for inlines
but honored only for the block is definitely a desirable behavior
for authors -- it's much more likely to lead to consistent line

In other words, if I were designing CSS from scratch, I'd probably
make the default 'block font replaced', rather than 'block inline
replaced' as CSS currently requires.  And I'd definitely do this
using the definition of 'font' that doesn't include 'line-height'.

You're right, though, that the quirks mode model isn't really like
'font replaced', in that it's using a variant of 'font' that does
include the line-height.


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Friday, 18 March 2011 18:21:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:44 UTC