[csswg-drafts] [css-text][css-text-4] Add a property to define when to stop trying to justify a line

AmeliaBR has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-text][css-text-4] Add a property to define when to stop trying to justify a line ==
## Rationale:

CSS Text Level 3 includes a [rule for how to give up on justification if the text in a line cannot be stretched at all](https://drafts.csswg.org/css-text-3/#justify-limits).  But sometimes a line of text *can* be stretched, just not in an attractive way.  The number of expansion opportunities cannot accommodate the amount of space that needs to be filled.  

For a not-entirely hypothetical example, consider a paragraph like this:

> There are two options for the `patternContentUnits` attribute: `userSpaceOnUse` (the default) or `objectBoundingBox`.

For reasons of accuracy, you do not want to introduce any hyphens or breaks in the code terms.  But this sentence is part of a larger text which is justified for aesthetics.

When constrained to a narrow column of justified text, that might look something like this:

```
There   are   two   options   for   the 
patternContentUnits          attribute: 
userSpaceOnUse   ( the   default )   or
objectBoundingBox.
```

No matter how smart your justification algorithm, it's going to look bad.

## Proposal: 

A `text-justify-limit` property defines the point at which justification is deemed unacceptable for a given line of text.  If the justification required for a line exceeds this limit, no justification is attempted, and the text is instead aligned according to `text-justify-last` (the same rule as if there were no justification opportunities in the line at all).

The value would be a percentage or a length.  

Lengths would define the maximum amount of space that can be added at any single expansion point. 
 In other words: divide the total amount of extra space that needs to be assigned by the total number of expansion points.  If it is longer than the limit, don't try to justify.  For inter-character justification, this is equivalent the maximum `letter-spacing` value.

Percentages would define the maximum increase in expandable characters, and would make sense for inter-word justification or character elongation. In other words, divide the total amount of extra space that needs to be assigned by the natural advance length of all expandable characters; if it is more than this percentage, don't try to justify.  So `text-length-limit: 100%` would mean do not use justification if it would more than _double_ the length of spaces (that is, increase them by more than 100%).   This is equivalent to how percentages work for `word-spacing`.  

## Example

Looking again at the problematic paragraph, set in monospace font for easy math, with a 40ch target width:

```
There   are   two   options   for   the 
patternContentUnits          attribute: 
userSpaceOnUse   ( the   default )   or
objectBoundingBox.
```

The expansion lengths and percentages for each line are as follows:

- "There   are   two   options   for   the": 10ch added to spaces that are normally 5ch total length = 2ch added in each opportunity, or 200% increase
- "patternContentUnits          attribute:" 9ch added to a space that is normally 1ch = 9ch or 900% increase
- "userSpaceOnUse   ( the   default )   or": 8ch added to 5 spaces that are normally 3ch total length (because normally there isn't any space on the insides of the parentheses) = 1.6ch or 266% increase

With `text-length-limit: 300%`, the second line would be deemed un-justifiable, and the layout would look like this (assuming `text-justify-last: auto`):

```
There   are   two   options   for   the 
patternContentUnits attribute: 
userSpaceOnUse   ( the   default )   or
objectBoundingBox.
```

With `text-length-limit: 1.9ch`, the first two lines would be deemed un-justifiable.  (Or, if the text layout didn't support adding extra space on the inside of the parentheses, all the lines would be un-justifiable.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1221 using your GitHub account

Received on Friday, 14 April 2017 20:41:04 UTC