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

Re: [css-text-4] text-wrap:balance take 2

From: Peter Moulder <pjrm@mail.internode.on.net>
Date: Sun, 8 Feb 2015 08:24:48 +1100
To: www-style@w3.org
Cc: Alan Stearns <stearns@adobe.com>
Message-ID: <20150207212448.GA20288@mail.internode.on.net>
On Fri, Feb 06, 2015 at 05:23:56AM +0000, Alan Stearns wrote:

> [Perhaps the not-fully-balanced case might be described as]
> 2. Try to fix a short last line without changing the “normal” line measure
> too much

I've already clarified that I don't think that "without changing measure too
much part" is really part of it (in fact I think we agree that these use cases
are more able to change their measure when necessary).  Here I'll comment on
the "fix a short last line" part.

If we consider the case of a higher end UA such as used in print,
I don't think we need a property to say "avoid short last line", because
such a UA should always *try* to avoid a short last line, even in body text.

The distinction between body text and the sorts of paragraphs we've
been discussing is not that a short last line looks worse[*1], but that
these paragraphs are more able to reduce their visible measure than
normal body text is.

For a web-browser-like UA, it might be that the main effect is to change
the effective line-breaking width to make a short last line less likely.

Whereas for a UA more like what Adobe or I would be working on, this freedom
can also be used to avoid other badnesses, whether in rag shape or in avoiding
weakly dispreferred break opportunities.

(Even a web browser might consider avoiding weakly dispreferred breaks if the
 resulting paragraph still uses only two lines.)

pjrm. 


[*1]: Indeed, these sorts of paragraphs don't have to contend with text-indent,
  and one might be more willing to prefer a short last line over a hyphenation
  for a pull quote than in body text.
Received on Saturday, 7 February 2015 21:25:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:28 UTC