Re: [csswg-drafts] [css-text] Preventing too-short final lines of blocks (Last Line Minimum Length) (#3473)

I've just changed the title of this issue to make it clearer that we're talking about orphaned words on a line, not orphaned lines on the top/bottom of a page or column (which is what the `widows` and `orphans` properties are about).

I came here because of [this thread by the CSS-Tricks team](https://twitter.com/css/status/1201147818745839616) about workarounds to avoid bad-looking breaks. This is clearly a common situation where people are modifying their markup to get typographically pleasant results, and that is really a problem that CSS should try to solve.

[CSS Text 4 has a heading for this topic ("Last Line Minimum Length"), with an issue summary but no solution](https://drafts.csswg.org/css-text-4/#last-line-limits), with a cross-reference [to a 2015 mailing list discussion](https://lists.w3.org/Archives/Public/www-style/2015Jan/0012.html). Copying over the current issue text from the spec:

> Issue is about requiring a minimum length for lines. Common measures seem to be
>
>- At least as long as the text-indent.
>- At least X characters.
>- Percentage-based.
>
> Suggestion for value space is ''match-indent | <length> | <percentage>'' (with Xch given as an example to make that use case clear). Alternately <integer> could actually count the characters.
> 
> It’s unclear how this would interact with text balancing (above); one earlier proposal had them be the same property (with 100% meaning full balancing).
> 
> People have requested word-based limits, but since this is really dependent on the length of the word, character-based is better.

My own opinions to get the discussion started:

I think the property should support a minimum number of characters (as an alternative to minimum % of inline size or minimum line length) for the final line. That covers most typographic style guides while still avoiding any discussion about what is or isn't a word across different languages, or when words are broken by hyphenation.

Since we're assuming that most implementations will be using a greedy line-breaking algorithm, maybe the property could accept a second value that would be the minimum number of characters for previous lines, at which point no more attempt at removing the widow should be made. (If the second value isn't specified, an auto behavior applies: don't make the second-to-last line shorter than the last line while trying to make the last line longer! In fact, this should apply regardless of whether you also specify a minimum length for the second-to-last line!)  If a more complicated [`text-wrap` justification algorithm](https://drafts.csswg.org/css-text-4/#text-wrap) applies, the rules about "second-to-last line" apply to all previous lines in the block.

```
min-last-line: 8 / 20; /* make sure the last line is at least 8 characters long,
               unless doing so would make the last line less than 20 characters long */
min-last-line: 3em; /* make sure the last line is at least 3em long,
               unless doing so would make the second-to-last line shorter */
```

Or maybe it would be better to have two properties: `min-line-last` which is specifically about avoiding the orphaned short line at the end of the block, versus `min-line` that is a hint about the ideal minimum length for any lines _except_ the last. In addition to avoiding over-compensation when padding the last line, it could define a trigger at which point smarter/more expensive `text-wrap` and hyphenation strategies should be employed.

PS, I think it would also be helpful if there were some figures in the spec about [widows and orphans](https://drafts.csswg.org/css-break/#widows-orphans) to make it clear that those properties *aren't* about bad line breaking, but about bad block breaking. If anyone wants to create that, I'm sure a PR would be welcome!

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3473#issuecomment-560136177 using your GitHub account

Received on Sunday, 1 December 2019 17:46:52 UTC