W3C home > Mailing lists > Public > www-style@w3.org > February 2013

Re: [css3-text] Balance Text proposal

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sun, 03 Feb 2013 03:10:28 +1100
To: Randy Edmunds <redmunds@adobe.com>
Cc: www-style@w3.org
Message-id: <20130202161028.GA24726@bowman.infotech.monash.edu.au>
On Thu, Jan 31, 2013 at 07:43:03AM -0800, Randy Edmunds wrote:

> Yes, [unchanged height] only applies to the intended and usual cases, but
> can't be guaranteed. I'll update the proposal to state the number of
> lines are invariant

I was thinking that a CSS spec would take a fairly permissive approach to
line-wrap:balance, just as it takes with line breaking generally.

(Ian Hickson gave some of the reasons for this in
http://lists.w3.org/Archives/Public/www-style/2005Nov/0020 .
That was in 2005; I don't know if opinions have changed since then,
but my experience is that UAs have actually become less interoperable in
line breaking since then, as UAs have tried to improve their line breaking
for competitive advantage -- as Ian hoped.)

I don't think it reasonable to guarantee that the number of lines is
unchanged as such, as different UAs can have a different number of lines
anyway.  Similarly, I don't suggest forcing a minimal number of lines:
for UAs that do hyphenation, "minimal number of lines" isn't
particularly meaningful, or rather the most obvious meaning isn't

Thus, I don't think that the proposal needs to mention number of lines at
all; or if it does then it would be with a qualifier such as "typically".

(Apart from that, the proposed algorithm doesn't actually guarantee that
the result will use the target number of lines, even without floats.  E.g.
it might finish a line early if the last word is twice the desired average

There's some value in giving an algorithm as a starting point, even without
handling floats, but I also think that the algorithm should clearly be
marked as not part of the proposal.  E.g. I'd remove most mentions of the
word "algorithm" before the Details section, and add something at the start
of the "Details" section to clarify the purpose of giving an algorithm,
e.g. "Below is a possible starting point for implementations of this

It wasn't obvious to me that the algorithm given doesn't always find lines
with minimal length variation; I think that would be interesting
information to include, as some UAs (e.g. print-centric ones) may well want
to use a non-greedy search.

Received on Saturday, 2 February 2013 16:10:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC