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:

• https://github.com/w3ctag/design-reviews/issues/864#issuecomment-1663539298
• https://github.com/w3c/csswg-drafts/issues/3473#issuecomment-1663560448

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

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.

bumped to f2f

Still waiting for feedback, pinged

Still pending feedback, pinged.

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

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

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

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:

1. 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).
2. 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.
3. 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.