Intent to Ship: CSS text-wrap: pretty

[Koji Ishii]

Contact emails

ko...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-text-4/#valdef-text-wrap-pretty

Design docs

https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?usp=sharing

Summary

Adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.) When `text-wrap: pretty` is specified, paragraphs that will end up with a short single word on the last line are adjusted so that the last line has two or more words. The algorithm is based on the Knuth-Plass algorithm, as used by TeX. It computes scores for all candidates, and chooses the best one. To balance between the typographic benefits and the performance impacts, it adjsuts the last 4 lines of paragraphs that meet certain conditions.

Blink component

Blink>Layout>Inline

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low. This value only sets a bias for better layout over speed, without any particular requirements. Browsers that don't support this value will fall back to their default line breaking algorithm, but both the exact line breaking results for this value and for the default value are not defined.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=630181)

WebKit: Positive (https://github.com/w3c/csswg-drafts/issues/672) This property is originally requested by an WebKit engineer.

Web developers: Positive (https://clagnut.com/blog/2424#:~:text=the%20specification%20is-,text%2Dwrap%3Apretty,-.%20If%20it%E2%80%99s%20ever) When Blink shipped `text-wrap: balance` that improved headlines, many tweets and articles are seen on the web, wanting the feature to avoid a single word on the last line (typographic orphans) for body text. https://medium.com/swlh/typographic-orphans-on-the-web-266e32f756fe has a simple JS solution to avoid typographic orphans. https://github.com/robertknight/tex-linebreak is a JS implementation of the Knuth-Plass algorithm, has 111 stars.

Other signals:

Ergonomics

Another related value of this property `text-wrap: balance` improves line breaking for headlines, while this value improves typography for body text.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None.

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1432798

Sample links

https://output.jsbin.com/hopejeb

Estimated milestones

Shipping on desktop

117

Shipping on Android

117

Shipping on WebView

117

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145771917180928

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Why was a TAG review not filed?

[Koji Ishii]

Sorry, filed here: https://github.com/w3ctag/design-reviews/issues/864

I thought the previous review covered this, but you're right that it didn't cover other values of `text-wrap`.

[Thomas Steiner]

Just as a side question: is this and the headlines feature too opinionated to become part of user-agent stylesheets? I’m not immediately saying it should be, I’m just curious if this was considered?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dKPpadQmZeRkXjmXax73OTN7MjgG1hQxQ5rfjN8uTcEDg%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Relations Engineer (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.3.4 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/

----- END PGP SIGNATURE -----

[Koji Ishii]

Hi, thank you for the question.

On Thu, Jun 22, 2023 at 5:15 PM Thomas Steiner <to...@google.com> wrote:

Just as a side question: is this and the headlines feature too opinionated to become part of user-agent stylesheets? I’m not immediately saying it should be, I’m just curious if this was considered?

The short answer at this point is no, we're not changing the user-agent stylesheets, but as you pointed out, there are two aspects in your question -- whether it should be or not, and how.

I think I can come up with cases where it should be, but at this point, I don't have enough confidence that it always should be. There are a wide variety of situations where browser's text rendering is used, including apps like text editors, games, forms, ASCII arts, and so forth. Also different languages have different typographic rules. Among them, I can find certain cases where it should not be. When changing the default settings, all such cases will need to be inspected. Web compatibility and the performance implication also need to be investigated more.

When a conclusion is reached, then the "how" part. Generally speaking, the user-agent stylesheets are where browsers are expected to be interoperable, so I think it should be discussed at the CSSWG. If you have opinions, you can post at <https://github.com/w3c/csswg-drafts/issues>.

On the other hand, the initial value `wrap` of the `text-wrap` property allows UA to use the algorithm for `pretty`, so UA can choose to do it without changing the user-agent stylesheets. I don't have a plan for doing it at this point as above, but if we reach a conclusion that Blink should do so, we will go through this "Intent to Ship" process as it will be a breaking change.

I hope this clarifies your question.

[Alan Stearns]

As one of the spec authors, I support the intent to ship the text-wrap:pretty value.

But I think we should be careful to avoid associating this value with only avoiding single-word last lines in a paragraph. Avoiding short last lines is one thing an engine can do with a more elaborate line-breaking algorithm. The intent of the value is to allow more experimentation in this space to eventually get more consistent line breaks and spacing overall. So while I am perfectly happy with this first step to avoid single-word last lines with a four-line window evaluation, we should be clear that future improvements are also welcome (like fixing a short last line with more than one word, or evaluating more than four lines in the paragraph to find a better solution).

We will also need to be clear that this value will not always guarantee that paragraphs will never end with a single-word line. There will always be degenerate cases where there is no improved score that can fix the last line. A toy example is:

Christopher
Alexander
ate pizza
too.

The only way to avoid the single-word last line in this example is

Christopher
Alexander
ate
pizza too.

which is not a improvement (and should show up as worse in any score-based evaluation of the paragraph)

[fantasai]

On 6/21/23 10:51, Koji Ishii wrote:
>
> https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?usp=sharing

>> Avoiding a short single word on the last line (typographic orphans) is one
of the most visible advantages of the paragraph-level algorithm.

What does it mean to “avoid a short single word” in quantitative terms (and
across languages)?

>> Following are the limitations as of ToT/WIP. The list may change in future.

Can you confirm that this table means that the “pretty” algorithm is disabled,
rather than the feature listed being disabled in favor of “pretty”? :)

> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or interop
> issues. Please list open issues (e.g. links to known github issues in the
> project for the feature specification) whose resolution may introduce web
> compat/interop risk (e.g., changing to naming or structure of the API in a
> non-backward-compatible way).
>
> None.

I'm also not aware of much in the way of spec changes that would introduce any
compat problems, since the spec gives a *lot* of leeway to the UA for this
feature; so I doubt changes would cause non-compliance.

Instead, the primary thing to analyze would ways in which Chrome's own
interpretation creates compat or interop issues, or locks in browser behavior
or Web-developer expectations that we may want to change later.

So I agree largely agree with Alan Stearns's comments, and in the context of
those comments, I want to ask, if the primary goal is to avoid short last
lines, is “text-wrap: pretty” the right approach, or should we be considering
a proposal that allows more configuration?

For example, there have been in the past a proposals for a property like
last-line-length: <length-percentage>
which is discussed in the issue you linked to:
https://github.com/w3c/csswg-drafts/issues/3473

Note that “text-wrap: pretty” was originally intended to apply better
line-breaking throughout the paragraph, not so much to control the length of
the last line.

~fantasai

[Koji Ishii]

Thank you Alan for the feedback.

On Fri, Jun 23, 2023 at 6:05 AM Alan Stearns <famu...@gmail.com> wrote:

As one of the spec authors, I support the intent to ship the text-wrap:pretty value.

Thank you, glad to hear your support ;-) 

 

But I think we should be careful to avoid associating this value with only avoiding single-word last lines in a paragraph. Avoiding short last lines is one thing an engine can do with a more elaborate line-breaking algorithm. The intent of the value is to allow more experimentation in this space to eventually get more consistent line breaks and spacing overall. So while I am perfectly happy with this first step to avoid single-word last lines with a four-line window evaluation, we should be clear that future improvements are also welcome (like fixing a short last line with more than one word, or evaluating more than four lines in the paragraph to find a better solution).

You're right, thank you for clarifying this. I should have clarified better that this is just an initial implementation, and I expect it to do more as you pointed out. The design doc mentions it but sorry, I didn't include it in this Intent.

 

We will also need to be clear that this value will not always guarantee that paragraphs will never end with a single-word line. There will always be degenerate cases where there is no improved score that can fix the last line. A toy example is:

[snip]

which is not a improvement (and should show up as worse in any score-based evaluation of the paragraph)

Again, thank you for pointing this out too. The current implementation is done by adjusting penalties, not by forbidding the breaks, so there are cases where it ends up with typopgraphic orphans depending on penalties and scores in other parts of the paragraph. The current penalties are determined from our testing, but we may adjust them further by future feedback. If it turns out that automatic heuristic penalties can't suffice all cases, I look forward to discussing at the WG how authors can control them.

[Thomas Steiner]

Thank you for the very detailed answer, Koji! Reading your response, I agree that this probably wouldn't be a web-compatible thing to change at the UA-stylesheet level, but great to have it available soon, so it can go in one's personal or community-maintained CSS frameworks.

[Koji Ishii]

On Fri, Jun 23, 2023 at 12:59 PM fantasai <fantasa...@inkedblade.net> wrote:

 >> Avoiding a short single word on the last line (typographic orphans) is one
of the most visible advantages of the paragraph-level algorithm.

What does it mean to “avoid a short single word” in quantitative terms (and
across languages)?

What does "in quantitative terms" mean? Are you asking the exact logic, not from common cases? If so, the logic at this point is when the last line is equal to or less than 1/3 of the available width, and has no break opportunities. Please refer to the "Performance Considerations" for more details. If not, appreciate it if you can explain your question better.

 

>> Following are the limitations as of ToT/WIP. The list may change in future.

Can you confirm that this table means that the “pretty” algorithm is disabled,
rather than the feature listed being disabled in favor of “pretty”? :)

Yes, updated the description. Thank you for pointing out this possible misleading text.

 

[snip]

So I agree largely agree with Alan Stearns's comments, and in the context of
those comments, I want to ask, if the primary goal is to avoid short last
lines, is “text-wrap: pretty” the right approach, or should we be considering
a proposal that allows more configuration?

As in Alan's comment and in the "Overview" of the design doc, the initial implementation includes avoiding typographic orphans, but the primary goal is to add more to improve typography incrementally. It's not easy to ship every possible idea at once, primarily due to the performance concern. The algorithms included in this Intent to Ship is about ~10% addition to the layout performance, while doing all I prototyped costs ~200%, and we're not sure "3 times slower" is acceptable for web developers at this point. We'd like to start small, then we're looking forward to developer feedback on which typographic improvements are more important for them and how much performance cost is acceptable.

For example, there have been in the past a proposals for a property like
   last-line-length: <length-percentage>
which is discussed in the issue you linked to:
   https://github.com/w3c/csswg-drafts/issues/3473

Yes, I agree this is a possible good idea too. I'm looking for if a) authors want to enable only this without other typographic improvements, b) authors want this even when we have higher-level control (`pretty`) enabled across browsers, and c) authors want to distinguish e.g., 33% vs 50%, but I need more research to get answers. I agree with Alan that starting from higher-level control looks like the right first step.

[Koji Ishii]

Thank you Thomas for further feedback. I agree that CSS frameworks can apply this property better as they know which class has headlines/body for articles better. I look forward to it to happen too!

[Rick Byers]

LGTM1

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJHcCJ8TzS6nG27Uem_6keVwTgArBPtFzg29KHiUOPumQ%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Cexu-4srZ7cOKKYrpz6AGu7ed1xnFU7gBjiGmPLzmkg%40mail.gmail.com.

[Alex Russell]

Have followed up again in the design doc. Would like to make sure that multiple (potentially competing) values for `text-wrap` have clear precedence and that we have a plan for adding new values (e.g., for full LaTeX flow for printing).

Thanks again.

Best,

Alex

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJHcCJ8TzS6nG27Uem_6keVwTgArBPtFzg29KHiUOPumQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Koji Ishii]

Thank you Alex for the feedback. Replied to the doc.

In short, I'm supportive of giving more controls to authors, to achieve a more similar level of the typography as LaTeX. There are multiple ideas how to do it in a world where multiple implementations exist. I think it will need further author feedback, experiences from other implementations, and discussions at the CSSWG.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJHcCJ8TzS6nG27Uem_6keVwTgArBPtFzg29KHiUOPumQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Larry LACa]

@ko..  Re: other implementations. 
There are a number of typographic styling efforts.  E.g. CSS-Pseudo-4
CSS-Pseudo-4 | w3.org

[Koji Ishii]

Thank you Larry for the feedback.

By "typographic styling efforts" do you mean other CSS features? If yes, thank you for pointing that out, I'll look into them for possible relationships with this feature.

When I wrote "other implementations", I meant "other browsers," as they may take different tradeoffs and get different feedback from their users. Sorry for not being clear, but I agree both should be investigated for improving typography more. Thank you.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/63834b8b-a61f-4a00-b9ea-48c650ab2129n%40chromium.org.

[Yoav Weiss]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.