Re: [css-text] Re: Follow-up on Balance Text Proposal

(fixing top-posting)

> On 10/13/14, 9:58 AM, "Bobby Mozumder" <mozumder@futureclaw.com> wrote:
> 
> > On Oct 13, 2014, at 11:44 AM, Zack Weinberg <zackw@panix.com> wrote:
> > 
> > > On Mon, Oct 13, 2014 at 9:12 AM, Bobby Mozumder
><mozumder@futureclaw.com> wrote:
> > 
> > > I'm also concerned that this is a "yes, fix this bug" switch.  Under
> > > what circumstances would one NOT want a headline, a section heading,
> > > or indeed an entire paragraph to be wrapped such that all lines are
>of
> > > similar length?  Wouldn't it be better to encourage browsers to
> > > implement better algorithms *which are on by default*?
> > 
> > 
> > > A good intro on where you would/wouldn’t use each:
> > > http://indesignsecrets.com/when-to-use-balance-ragged-lines.php

> > 
> > 
> > I'm not a designer, but? The example presented of "worse with balance
> > on" looks better to me with balance on.
> > 
> > Still, I wouldn't be opposed to a specification along the lines of
> > 
> >    text-wrap: normal
> > 
> >        Default behavior: break lines as typically appropriate for
> >        body copy.  There is no constraint on the number of words
> >        on the last line of each paragraph.
> > 
> >    text-wrap: balance-lines
> > 
> >        As 'normal', but make the last line of each paragraph of
> >        similar length to the others.  This is often the desired
> >        behavior for headings, pull quotes, and centered text.
> > 
> > which I think captures the desired destinction, but says nothing that
> > would require the use of a specific algorithm for either mode.
> 
> 
> You’re looking at a single paragraph example there.
> When you have long body copy with dozens/hundreds of
> paragraphs, you don’t want balanced lines throughout,
> that really looks bad and ends up being confusing reading
> and you might end up losing your place in the text.
> 
> 
> It’s better to indicate distinct paragraphs with some
> spaces at the end. (but not too much space so that
> there’s a single character or two in the last line,
> which is also an unoptimal situation.)

I think there are really (at least) two distinct features we’re discussing.


The first is balanced lines as Bobby defines them. Line breaks are chosen
to normalize line lengths. You generally do not want this in body text, as
it can result in strange inconsistencies across paragraphs in either line
length (for ragged text) or spacing (for justified text). It’s very useful
for headings, captions, and standalone paragraphs.

The second is controlling the last line length - avoiding a single
character or a single word on the last line of a paragraph. In this case,
you can fiddle with more knobs than just line length. You might choose
slightly looser spacing or even increase the differences in line lengths
across the paragraph in order to avoid a lonely word at the end. I think
this feature works best within a multi-line break system, where an optimal
last line length can be factored in with all the rest of the inputs.

What I recall is that the last proposal we talked over for CSS Text 4
added these two features together. A last-line-length property would take
a percentage and perform as the second feature unless its value was 100%.
At last-line-length:100%, you’d get the first feature. At the time I
thought that would be OK, as I do want both of these features available in
CSS.

After some reflection I think they should be separate properties. We
should do balanced lines now as a simple switch, and work on last line
length some time in the future when we have multi-line composers to work
with.

And I agree (and I think everyone else does as well) that the spec should
not require a particular algorithm. I think the algorithm presented is
useful, as proposals for balancing lines have failed in the past on
performance arguments. Showing a method to balance lines without iterative
layout may be necessary to convince a few people the feature is viable.
But we should definitely only define the intended result and leave the
method open to improvement.

Thanks,

Alan

Received on Monday, 13 October 2014 17:41:00 UTC