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

Re: Updates to section 10.8.1

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 3 Mar 2009 09:31:45 +0900
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20090303003145.GA27546@pickering.dbaron.org>
On Friday 2009-02-27 11:10 +0100, Michael Jansson wrote:
> I'm still trying to understand the line layout formatting that is  
> described by CSS 2.1. Having read Mike Eric Meyer's inline formatting  
> model 'cheat sheet' at http://meyerweb.com/eric/css/inline-format.html,  
> I believe it describes what most browsers do (more or less), but I don't  
> like what I see from a typographical point of view.

Between CSS 2.1 and what I think you're proposing, there's a
tradeoff between having the model produce results that don't cause
horrible overlapping when the exact fonts the author expected aren't
present and producing evenly spaced lines.

In terms of the line-box-contain property described in the draft at
http://dev.w3.org/csswg/css3-linebox/#line-box-contain what CSS 2.1
specifies is 'block inline replaced', the browser quirks mode
behavior is 'font replaced'.  I'm not exactly sure which behavior
you're proposing ('block replaced'?  'block font replaced'?).

However, I think there are values, such as 'block font replaced'
that make a reasonable compromise between both sides of this
tradeoff:  they tend both to avoid unintended overlapping and to
produce evenly spaced lines when possible.

I think for Web compatibility we're pretty constrained as far as
changing the default behavior here.  I'm also not a big fan of
mode-switching properties (despite having proposed this one a long
time ago).

I'd also note that I don't think we want to cater for the "exact
positioning" use case, especially when unknown fonts are being used.
(But even with downloadable fonts, there are likely to be
differences between systems.)


L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Tuesday, 3 March 2009 00:32:22 UTC

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