design-reviews#864: text-wrap: pretty

#864: text-wrap: pretty

Opened Jun 21, 2023

Hello TAG!

I'm requesting a TAG review of text-wrap: pretty.

This feature adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.) This is another value of the text-wrap property, once reviewed for balance at #822.

Explainer¹ (minimally containing user needs and example code): url
Specification URL: spec url
Tests: wpt folder(s), if available (note this contains both balance and pretty)
User research: [url to public summary/results of research]
Security and Privacy self-review²: [url]
GitHub repo (if you prefer feedback filed there): [url]
Primary contacts (and their relationship to the specification):
- @kojiishi (Implementer), @bfgeek (Implementer), @fantasai (Spec Editor)
Organization(s)/project(s) driving the specification: Google
Key pieces of existing multi-stakeholder review or discussion of this specification:
External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5145771917180928

Further details:

I have reviewed the TAG's Web Platform Design Principles
Relevant time constraints or deadlines: Implementation complete.
The group where the work on this specification is currently being done: CSSWG
The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
Major unresolved issues with or opposition to this specification:
This work is being funded by: Blink implementation is being done by Google.

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

Discussions

Discussed Jul 1, 2023 (See Github)

Lea: Been looking at it - and pinged spec editor - who was not in agreement that a TAG review should be requested and had concerns about the Chrome implementation. This has a generic name for a reason: it's supposed to be a way for UAs to use a mix of heuristics to maximise line breaking aesthetics. Develoeprs were evangelizing it as a way to avoid orphans because that's all this implementation did, and there was no way to control orphans specifically... If you ship something that is supposed to employ a mix of heuristics with only one heuristic, authors will learn to depend on that to control this one thing and you can never change it. There's a CSS WG resolution for a separate property for orphans, and also they are open to shipping pretty with more than one heuristic.

Lea: i've given this feedback - they've replied, they're receptive.. don't know what else there is to do here...

Dan: issue of people asking for TAG review ... they should know that it's part of wide review ... also they should ensure that other editors and group chair have visibility / approval of that review request

Dan: "are you in the group? did the group produce the document? then you're proposing it."

Lea: to write comment I will direct that the CSS WG more appropriate for specific heurtistics...

Comments posted:

Comment by @fantasai Jul 20, 2023 (See Github)

@LeaVerou asked me to explain this feature and the potential compat impact etc.

This feature adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.)

This is not an accurate description. The text-wrap: pretty value is defined to ask the UA to apply more resources into line-wrapping and justification in order to make the text look “prettier”. The concerns that this is expected to balance include

reducing the raggediness of the lines (reducing variance in their lengths), which makes the end edge look more even when not justified, and reduces the variation in justification space adjustments between lines when fully justified, thus improving readability as well as aesthetics
avoiding rivers
applying smarter line-breaking prioritization, to avoid awkward breaks
etc.

Avoiding too-short last lines is certainly one aspect that can be considered by a UA for text-wrap: pretty, but it's only one of the things we expect the UA to consider. So while an implementation that only adjusts the last line length in response to text-wrap: pretty would be conformant to the spec (which gives a lot of leeway on interpreting pretty), it's a limited interpretation.

This presents a risk that authors, who really really want last-line length adjustment, will interpret text-wrap: pretty as a “make the last line length less short” control rather than “do lots of different expensive things to make it prettier”. I'm not entirely sure of the compat impact of that going forward, it might not be much. I am fairly sure, however, that it will create some confused messaging when the feature is evangelized, though, as it will be taught as “use this weird hack to fix your too-short last lines”.

I'll note there's also been discussion over the years of having a specific control for last line length; there's no draft yet because implementations weren't interested until now. But we do have the possibility of providing a specific feature for this specific implementation feature, and that may be a better path forward for this feature request.

Comment by @LeaVerou Jul 22, 2023 (See Github)

Hi there,

We looked at this in the plenary on Wednesday.

In general, we recommend explainers to be in Markdown, and are in the process of merging guidance to that effect in the Explainer Explainer. Some more reasons for this in https://github.com/w3ctag/explainers/issues/14 .

We were also a little confused about the name, since it seems that this feature is about controlling orphan words and pretty is very generic, which is why I reached out to @fantasai for clarification after the call.

If the intent of the spec is to have many varied heuristics into making text wrapping more aesthetically pleasing, I am a little worried about whether the current implementation can evolve into this eventually. I can easily see authors starting to use it as a property to control orphans, and before we know it, we can’t change it due to web compat. The way authors are already evangelizing it so far confirms these fears.

If all this property does is prevent orphan words, I wonder if a property to control exactly that would be preferable, possibly as a longhand of text-wrap (text-wrap-orphans?). This could also give authors more control, and would be far more discoverable.

(To clarify, everything using first singular is my personal opinion, and does not necessarily reflect TAG consensus — I use first plural to express that)

Comment by @kojiishi Jul 28, 2023 (See Github)

If all this property does is prevent orphan words

To clarify Blink's intent, this property value should be able to do more, but the initial implementation in Blink focused on preventing orphaned words. Please see the discussion in Blink I2S and the "Overview" section of the design doc. Blink is planning to add more typographic improvements to the pretty algorithm incrementally.

Comment by @LeaVerou Jul 28, 2023 (See Github)

To clarify, I think it's ok for it to ship with fewer heuristics and evolve over time, but it needs to implement at least two to avoid authors using it as a proxy for a more specific thing.

Comment by @kojiishi Aug 1, 2023 (See Github)

That's a very good point, thank you. We saw many strong feedback on avoiding orphans from web developers (example 1, 2) and it wasn't easy to determine the next strong request from the feature candidates.

But it's also not difficult to pick one more feature, if we put the request priority aside. I'll think about it.

Comment by @LeaVerou Aug 1, 2023 (See Github)

It may still be a good idea to expose orphans via a more targeted property as well, e.g. see this issue about a property specifically about orphans. That would satisfy the golden rule of API design: common things should be easy, complex things should be possible.

Comment by @kojiishi Aug 1, 2023 (See Github)

Yes, thank you, we're aware of the resolution at csswg#3473.

RESOLVED: Add a control that is either a property or a value that causes UAs to make the last line longer than it would've originally done unless that was a bad idea

We're willing to support the new value once the syntax is finalized.

Comment by @kojiishi Aug 2, 2023 (See Github)

From our prototypes, adjusting hyphenation penalties under certain conditions seems doable without hitting the performance much, so I'm planning to add it to pretty, while keeping the new value only for typographic orphans.

Comment by @LeaVerou Aug 3, 2023 (See Github)

Hi Koji,

We discussed this today in a breakout. This sounds like a plan. It may be good to try and ship orphan control at the same time as text-wrap: pretty to further avoid the possibility of developers using this as a proxy for orphan control.

We think the specific heuristics to employ are better decided within the CSS WG (not necessarily as a normative part of the spec), however we'd recommend the multiple heuristics employed by text-wrap: pretty are in the same "caliber", i.e. not something major like orphan control plus something that seems minor from the authors' point of view, otherwise it may still be used as a property for orphan control, with the understanding that it also "has some quirks", especially if it's the only way to do orphan control in CSS.

Comment by @kojiishi Aug 7, 2023 (See Github)

Thank you for commenting to the issue, that helps.

For your second part, sorry I don't understand what the neuance of "caliber" is, please disregard if I seem to misunderstand, but if you consider hyphenation is minor and you're looking for some other major features in Knuth-Plass, it may be difficult. The 3 top areas Knuth-Plass can improve are hyphenation, justification, and typographic widows/orphans control. For example, https://github.com/w3c/csswg-drafts/issues/672 has 8 candidate improvements, 3 are about typographic widows/orphans, 2 are about hyphenations, and 3 are about justification. Another example, this article expects pretty to improve typographic widows/orphans and better spacing, and "better spacing" is more important when the text is justified.

I fully agree having a separate control for typographic orphans is good, but if pretty means using more sophisticated non-greedy algorithms such as Knuth-Plass, I think it's reasonable to expect its outcome is minimizing typographic widows/orphans plus minor features, if we consider hyphenation and justification are minor.

Discussed Dec 18, 2023 (See Github)

waiting for a reply from Lea - maybe ready to close?

Discussed Jan 8, 2024 (See Github)

Lea: so – there is an existing value we introduced textwrap:balance - useful for headlines - often too draconian... so textwrap:pretty introduced as a high-level way to get nicer looking text balancing. The problem is that when the implementation shipped in chrome it only prevented ofphans... so devs got used to this... and it was seen only to prevent orphans... so not able to add new things. Our feedback was : give authors low-level control - but also if you ship the high level thing don't make it just do one thing... and they agreed... we also said "don't ship something that does one major thinng plus a minor thing" - and I see that koji asked for clarifications but we didn't reply...

Dan: ask what current status is? major/minor feature type thing? looks like they've taken our feedback on board. According to chrome status other vendors support it but they don't link to standards positions. I wonder if they've received this type of feedback from other parties

Thanks for bearing with us - we realize this response is late.

There's no way to quantify what is minor, the end goal is to ensure that authors do not use this as a proxy for a single feature (preventing orphans) which would prevent it from including more heuristics in the future. So in addition to preventing orphans, the property should control at least one more factor that is noticeable in common usage.

Preventing "rivers of white space" in justified text is certainly not minor, but we'd love to also see something that makes a visible difference in other text alignment modes as well.

Again, this becomes less of a concern if lower level control over orphans ships at the same time (or earlier).

Also - can you please elaborate on the multi-implementer support - we see that the Chrome Status page lists Webkit and Mozilla as positive but does not link to standards positions.

</blockquote>

Comment by @LeaVerou Jan 8, 2024 (See Github)

Thanks for bearing with us - we realize this response is late.

Preventing "rivers of white space" in justified text is certainly not minor, but we'd love to also see something that makes a visible difference in other text alignment modes as well.

Again, this becomes less of a concern if lower level control over orphans ships at the same time (or earlier).

Also - can you please elaborate on the multi-implementer support - we see that the Chrome Status page lists Webkit and Mozilla as positive but does not link to standards positions.

Discussed Jan 15, 2024 (See Github)

bumped to f2f

Discussed Feb 26, 2024 (See Github)

Still waiting for feedback, pinged

Comment by @plinss Feb 26, 2024 (See Github)

Hi @kojiishi any response to Lea's questions above?

Comment by @kojiishi Feb 26, 2024 (See Github)

Sorry for late, filed them here: https://github.com/mozilla/standards-positions/issues/993 https://github.com/WebKit/standards-positions/issues/324

Discussed Apr 22, 2024 (See Github)

Still pending feedback, pinged.

Discussed Apr 29, 2024 (See Github)

Pinged Koji to answer the rest of Lea's questions.

Comment by @hober Apr 29, 2024 (See Github)

@kojiishi what about @LeaVerou's other questions?

Discussed Jun 17, 2024 (See Github)

Tess: I saw a message on social media - that authors should apply textwrap:pretty using the universal selector... text wrap: pretty is expensive... It's an attractive nuiscance, but this advice of applying it to all elements could make browsers ignore it... So we don't like to bikeshed names but ... the name is harmful in the IETF sense of harmful.

discussion of the inefficiency and therefore the sustainability of this technology

Peter: a number of different things you can do make text "pretty" - it's not clear what this does and it's up to the UA... it's not clear what it's asking for beyond auto... Maybe the author only wants one of the algorithms, not the whole suite... I think we've left feedback.

Tess: there are times you know that incremental re-layout isn't good... for example, print stylesheets... there are screen cases as well...

Peter: e-book readers are an example...

Tess: common case is... you shouldn't use it in a typical case...

Dan: it's not clear that it would result in people not using it if you change the name

Tess: sure. But maybe less people will use it. Once the amount of content that relies on it is sufficient to cause browser benchmarks to be affected. if wikipedia adopted it.. browsers would have to break the feature. You'd have to make it equivalent to auto.

Dan: considering many developers also care about perf you could also say that one answer is to ensure all developer documentation includes a warning..

Tess: but naming the feature is documentation.. the most immediate form. I don't have to go to MDN to find out it's costly, if it's called text-wrap: costly. Make it viscerally obvious. I think this all came up in the WG. We should give them this advice.

Dan: are we going to keep this open?

Tess: rather wait for a reply.

Amy: could the browser just ... not allow it for universal selector...

Tess: i don't know of any css feature that works like that and in some cases...

Yves: maybe could be applied to print only and not screen...

Tess: Might not be the worst idea...

Peter: also it's an inherited property... so you can set it on body...

Lea: I don't think applying it to print only would fix all the issues.. one of the issues is that this is a high level feature that controls low level knobs. But there aren't enough low level knobs. So people might use this as a proxy for other things which should really have their own controls... You do a high level feature like this when you ...

Tess: browsers can also compete on how they implemen these approaches...

Lea: depends how well that works when approaches are incompatible. Should probably have a principle...

Tess to leave feedback

Comment by @hober Jun 17, 2024 (See Github)

The TAG looked at this again in a breakout today, and we returned to the naming issue. The name pretty doesn't convey to authors that this feature is computationally expensive, which may lead to more widespread adoption than is desirable, which will harm the real-world performance of sites. (That is, text-wrap: pretty is an attractive nuisance.) This concern isn't theoretical: consider this social media post encouraging authors to unconditionally apply text-wrap: pretty to everything:

💡 CSS Tip!

Enhance your text wrapping using two lines of code. No more lonely words at the end of paragraphs, and titles will look much better.

Will you add this to your CSS reset?
* {
  text-wrap: pretty;
}
h1,h2,h3,h4,h5,h6 {
  text-wrap: balance;
}```

If this feature gets over-adopted by authors eager to improve their sites, to the point where it starts affecting benchmark scores, browser engines will be disincentivized to implement text-wrap: pretty as anything other than an alias for text-wrap: auto, reducing the utility of the feature to zero.

We encourage the working group to rename the property value to something that reflects its costs as well as its benefits.

Discussed Aug 26, 2024 (See Github)

This is pending external feedback since Tess' comment on 17 June.

some discussion on this point

Jeffrey: I can poke the implementers to raise this with the working group... it might be a good idea to raise the issue directly with CSS...

Tess: I can look ...

Dan: can we close?

Jeffrey: I think satisfied with concerns would make sense... ?

Dan: if it's an issue that is actively being worked on then it would be satified.

Jeffrey: can we say 'hyphenation with oprphans is sufficient'?

Tess: I think satisfied with concerns is overstating it...

Jeffrey: it's an easy enough thing to change... blink could ship an alias... if the wg has already discussed "pretty" and said it's the right name then we should accept that...

bumped to next week

Comment by @hober Aug 26, 2024 (See Github)

@kojiishi @bfgeek @fantasai, has there been any further discussion of the above issue in the CSS WG?

Comment by @jyasskin Aug 26, 2024 (See Github)

I've filed https://github.com/w3c/csswg-drafts/issues/10785 to encourage the CSSWG to discuss the naming question. My sense from the discussion today was that the TAG will accept the CSSWG's expertise on this issue, as long as they've actually considered it. I also got the sense that including hyphenation in text-wrap: pretty's behavior (as Chrome has now) is sufficient to avoid the concern that this property will be used as a way to just control orphans, especially given the evidence that at least some authors do notice the change in hyphenation behavior.

Comment by @tabatkins Aug 26, 2024 (See Github)

As noted in https://github.com/w3c/csswg-drafts/issues/10785, it's been a year since the original TAG review request; at this point it's far too late to do naming changes unless something is genuinely broken (which I think it's clear isn't the case here).

Discussed Sep 2, 2024 (See Github)

Jeffrey: filed an issue with CSSWG. Tess suggested a more obvious name. Chrome said it's too late to change the name. Close to closing last week. Should we argue more?

Amy: would arguing more make a difference?

Jeffrey: only if other engines agree but they haven't weighed in. Name comment was a year after the issue was opened, so a bit late.

Lea: all we had are concerns..

Jeffrey: Lea left a comment last year...

Lea: they said pretty has orphan control plus this niche thing that only applies when you're doing justification

Jeffrey: I don't know if they shipped the rivers control. It changes how hyphenation works, and they did ship that (and got a complaint in the CSS discussion). An author wanted to do just orphans and not change hyphenations

Lea: that's what I was saying! They can't just ship this bag of things without shipping the individual knobs as well. People end up using pretty as a proxy for them.

Jeffrey: and now they can't, but also don't have the individiual knobs. Florian didn't like the idea of the individual knobs

Lea: I don't understand the problem with the individual knobs. it can't be that tricky to implement, just syntax

Jeffrey: I think Florian's worry was they then have to specify how the knobs interact with each other and authors will want control over how much do we sacrifice hyphenation in order to get a better last line, balancing the various things. Pretty just asks the UA to do something sensible.

Lea: this is a solved problem. There are already typesetting problems... how dothey do it? No checkbox in indesign called Pretty. There is control over the individual knobs but it's not a problem

Jeffrey: indesign is generating a page, doesn't have to be responsive to widths... not an expert in typesetting

Lea: anything that does the typesetting once is not a great example for perf, but in terms of exposing the knobs we can look ... prioritisation between different knobs and how conflicts are resolved. Does that affect perf?

Jeffrey: I don't know. I'd guess not.

Lea: if it doesn't, I don't see why we can't look at how existing software has solved this with a lot more years of experience into what people want from typesetting

Jeffrey: CSSWG should have this discussion. We should close on our end.

Lea: true. Satisfied is that we agree there's a pain point, concerns are we don't like how this is being solved. Pretty sure we haven't used satisfied with concerns for this in the past

Jeffrey: I don't feel strongly

Lea: eg. picture in picture.

Jeffrey: Florian's objection

Lea: balance seems like a low level knob, not sure how you'd decompose that. We didn't say only do the individual knobs.

Jeffrey: it actually doesn't sound like they're firmly opposed to adding the individual knobs, just not ready yet. So shipping pretty was dangerous as long as it just controls one thing. But now it controls two it's less dangerous. people who only want to control orphans will run into problems.

Lea: the second thing it controls only applies in a very specific case?

Jeffrey: I think hyphenation shows up not only when you're justifying text

Lea: I suppose there's a lot of correlation between hyphenating text and using this property. There's a design principle about high and low level features. Here they've shipped the high level feature first and I'm not convinced there is enough knowledge of what authors want, so I suspect pretty is going to end up changing over time and we'll run into web compat issues.

Jeffrey: so we're worried this is going to change in the future because we don't know what authors need, and that will cause web compat issues, and we'd like the CSSWG to revisit this.

Lea: yeah. Good line breaking is about a lot more than limiting hyphenated lines in a row and avoiding orphans. It would be an excellent name for a whole algorithm with smart line breaking.

Lea: We don't have a good sense of how intensive the final performance will be

Jeffrey: will continue to work on this comment after the call

Draft comment:

While we recognize that the author pain points this is designed to solve are real and prominent, we still have several concerns about this solution, both in terms of its current definition, and its timing.

In general, shipping high level features is a good idea when a) we have a good idea of what a good solution to author needs would be (either by first shipping low level features and observing how they are used OR because the solution is so obvious that this step is not needed) or b) the corresponding low-level features would be very tedious to use to produce the same result.

In this case, neither of these appear to be true: we do not have a good sense of what text-wrap: pretty should end up doing in the end, and it currently only corresponds to two very specific features, that would not be tedious to set individually.

One author's reaction to this feature appears to validate this concern: they wanted control over orphans and are frustrated they have to accept re-hyphenation to get it.

Given this, we are concerned that the behavior of this feature will need to change a lot over time, and that after a certain amount of adoption, those changes will either break web compatibility, or will require a high enough performance cost that browsers won't be able to ship them. We encourage the CSSWG to:

keep working to expose the lower-level features so authors can request them directly (e.g. if their intent is to avoid orphans, they should be able to express this without having to resort to a feature that combines it with other things).
work on a plan to ensure that implementations can eventually ship a truly-pretty line-wrapping algorithm even if that turns out to be expensive.
consider whether the completely open-ended specification for text-wrap: pretty ("Specifies the UA should bias for better layout over speed, and is expected to consider multiple lines") was the right way to get engines to ship evolvable and eventually-compatible implementations.

We think the CSSWG is the right place to pursue those goals and that parallel discussion within the TAG won't help anyone. Thus, we're closing this as Resolution: unsatisfied with the acknowledgement that solving the above problems would likely turn this into a satisfied resolution.

</blockquote>

Comment by @jyasskin Sep 4, 2024 (See Github)

One author's reaction to this feature appears to validate this concern: they wanted control over orphans and are frustrated they have to accept re-hyphenation to get it.

keep working to expose the lower-level features so authors can request them directly (e.g. if their intent is to avoid orphans, they should be able to express this without having to resort to a feature that combines it with other things).
work on a plan to ensure that implementations can eventually ship a truly-pretty line-wrapping algorithm even if that turns out to be expensive.
consider whether the completely open-ended specification for text-wrap: pretty ("Specifies the UA should bias for better layout over speed, and is expected to consider multiple lines") was the right way to get engines to ship evolvable and eventually-compatible implementations.