[csswg-drafts] [css-text-4] text-wrap: balance feedback following the experimental Chrome Canary implementation (#8516)

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

== [css-text-4] text-wrap: balance feedback following the experimental Chrome Canary implementation ==
- 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/@scott@typetura.social/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](https://front-end.social/@kizu/109950311807606358) 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 :)

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 March 2023 09:56:11 UTC