[css-text-4] text-wrap: balance feedback following the experimental Chrome Canary implementation

[kizu]

• Spec in question: https://drafts.csswg.org/css-text-4/#valdef-text-wrap-balance
• Experimental implementation tested in: Chrome Canary, Version 113.0.5626.0.
• Mastodon thread which I'm copying some of the feedback from: https://front-end.social/@kizu/109949954768539428 (a branch of @una's thread — https://front-end.social/@Una/109949776661803793)
• My few quick tests: https://codepen.io/kizu/pen/ZEMeyrz https://codepen.io/kizu/pen/zYJZzQK

I would list a number of issues that I think could be discussed here, enumerating them, but not splitting into several issues (I imagine we could do this later if something would be more actionable, would require a much lengthier discussion that would be possible in this issue).

1. The experimental implementation does not support any text-align rather than left (or, rather it works, but incorrectly, only aligning text inside the shrunk “balanced” box, not aligning that final box itself).

   I imagine that this is kinda covered by the spec, but probably could be something to elaborate on, especially touching on text-align: justify (I would mention it in point 4).

2. The experimental implementation does not support float — when it is present, the balancing just stops working. Unclear if this is intended on their part, but the spec mentions float explicitly, though does not elaborate how exactly it should be considered:

   The remaining space to consider is that which remains after placing floats and inline content

3. The experimental implementation is very buggy with initial-letter, where it seems to be applied at an incorrect time. I imagine there could be other features that could be similar? Maybe it would worth it to add those to the spec in the same list as “after placing floats and inline content”.

4. The experimental implementation seems to be very primitive overall — it is basically just a greedy pseudo-balancing, where the component's box seems to be shrunk until it starts wrapping to the next line, not checking/balancing any real line widths etc.

   While this is ok from the “The exact algorithm is UA-defined” standpoint, I can see how this exact behavior can be more explicitly defined, as it seems intuitive and more straightforward to implement, with the main exception being justify, as it would be much harder to fix the overall text-align issue, where for center/right aligned box we could just move that pseudo-box to the proper position, but for justify things would need to work on a very different level.

   Overall, I would really like to see less “UA-defined” algorithms in the spec, but maybe there is a way to have both finite defined algorithms for some keywords, and the more “smart” balancing separately?

5. The experimental implementation uses max 4 lines of balanced text instead of the 10 defined in the specs, quoting them having perf issues with more than 4 lines. I don't know the specifics of their algorithm, so it is either not super effective (if it is brute-forcing by doing something like a binary search for the narrowest non-wrapping state for the current number of lines — that can be not optimal), or means that even a primitive implementation is much more performant-heavy than anticipated, so maybe the limit in the specs could be rethought.

6. One piece of feedback from someone in the original thread (https://front-end.social/@[email protected]/109950006693445687 by Scott Kellum) was that if we have a limit, maybe there is a room to allow defining which lines we would want to balance, where we could sometimes want to balance the last 4 lines not looking at what other previous lines are doing, and that could be enough for most of the real use-cases, where the most issues are usually in the end of the header/paragraph.

7. One point I noticed when playing with the broken text-align was the fact that with the way the current experimental implementation works, it would be really cool to allow somehow using this balanced width as the “shrunk-to” width of the wrapped blocks, where currently wrapped blocks expand to fully fill their available space. At least with the way this experimental implementation works — having this separate box that gets stuck in one place — maybe this is something that can be implemented. My hard-coded implementation of what I want with container queries — https://codepen.io/kizu/pen/RwYpZeO

   Though, this is probably a completely separate issue from this, but if we would consider that for properly balancing lines we need to know those lines' lengths, and given we could have a limit of 4 (or N) lines — those seem like things that can unlock that wrapping issue we currently have in CSS, and maybe could be a part of the text-wrap spec or something?

Let me know if something is unclear, would be happy to test more scenarios if someone would want to :)

[clagnut]

Test case for illustrating the text-alignissues in point 1: https://codepen.io/clagnut/pen/XWPMLZW

[kojiishi]

Thank you @kizu for the detailed feedback, they're all greatly appreciated.

I think the text-align issue is an implementation issue. This is now fixed in the next Canary. Floats and initial-letter are also probably implementation issues too. In general, I think implementation issues can get better attentions from implementors at the implementation issue trackers (e.g., Chromium issue tracker.) You can also track changes to this implementation in Chromium here.

Regarding your point 4, please see #672 for some of reasons not to define th exact algorithm. I agree with you that defining more details has good aspects, but it has both sides. I hope you understand we want a good balance between the two. If you think the current balance should be adjusted, I think filing a separate issue would help getting attentions and easier to discuss. /cc @litherum @nt1m

Regarding your point 5. Other implementations may take different approaches, but in Chromium, I would like the initial version to be not too slow, so that even performance-sensitive sites could try. That should give us more data how much web authors want to accept the performance degradations for better quality. We can learn from it to improve further. I'm hoping to experiment non-greedy algorithms for text-wrap: pretty in future, and I hope the data should help us doing it.

Your point 6 and 7 look like new interesting ideas to improve the feature further. I think they are better discussed in separate issues.

[kizu]

Hey hey, @kojiishi, thanks for implementing this!

I think the text-align issue is an implementation issue. This is now fixed in the next Canary.

Awesome!

In general, I think implementation issues can get better attentions from implementors at the implementation issue trackers

I agree that filing those in the appropriate trackers could be ideal, and now that I know the exact issue for the text-wrap: balance, I could easily do this if/when I would encounter other issues.

Though, I'd say I think there is still reason to report things like I mentioned here: specs wording could always be improved, and the more clear and precise it is, the easier it is for implementers to get it right, and for the developers to understand what some given CSS would do, so mentioning issues that appear and if they could be clarified in the specs seems like a good idea to me.

Regarding your point 4, please see #672 for some of reasons not to define the exact algorithm. I agree with you that defining more details has good aspects, but it has both sides.

Thanks, would read that! I understand it, and would just re-iterate that I find the current Canary implementation acceptable and logical enough that this exact behavior could probably be worth it to define in the specs themselves, while leaving some kind of “pretty” which is subjective to a specific UA more open-ended.

If I was to dream big, I would propose allowing developers to have a much finer control over all of this — basically how cool it would be if authors could control all the points mentioned in the #672 by themselves, not just relying on the UA to make some generic averagely good solution? But this is probably too ambitious :)

I would like the initial version to be not too slow, so that even performance-sensitive sites could try.

Agree that this is the best path, and what I propose is to adjust the specification to match that, so it could also start with just 4 lines, maybe mentioning that this could be expanded in the following versions. This would remove the burden from the UAs and questions from the developers who would encounter the difference between the specs and implementation.

[tabatkins]

While this is ok from the “The exact algorithm is UA-defined” standpoint, I can see how this exact behavior can be more explicitly defined, [...] Overall, I would really like to see less “UA-defined” algorithms in the spec, but maybe there is a way to have both finite defined algorithms for some keywords, and the more “smart” balancing separately?

Note that ordinary line-breaking is also undefined in significant ways; the exact same text and styles can break differently across browsers due to differences in text layout engines, break-determining algos, etc. Text-wrapping is simply untestable in full; you can only verify that relatively extreme/obvious results do approximately what you expect. Exact matching for any of the more advanced text wrapping algos is thus already entirely off the table.

[brettmhoffman]

Very excited about this feature, particularly as a designer as well. I implemented it recently to test and have a simple page title, "Implementation & Metrics", but it's currently breaking the last two letters of the long word onto the next line, like so:

Implementati
on & Metrics

This is inside of a flex container that's not full-width of the page, but there is adequate space available to accommodate the full word, "Implementation", but it's still breaking.

[kojiishi]

@brettmhoffman When reporting an issue in browsers, it is recommended to attach a test case; a real page or ideally a minimized reproducible test page, so that people reading your post can reproduce the issue.

Also, are you seeing issues in one of Chromium-based browsers? If it's a browser-specific issue, it's better to post to browser issue trackers (https://crbug.com/new if Chromium-based brosers.)

[brettmhoffman]

@kojiishi Thanks for the insight, I'll head over there.