Repository navigation
[css-text] Should text-wrap-style:balance be allowed to affect the block height? #10186
Description
The description of text-wrap-style: balance says that balancing "must not change the number of line boxes the block would contain if text-wrap were set to auto."
My assumption is that this restriction is intended to ensure that applying the 'balance' setting to a block of text will only adjust the line-breaking used within the block but will not affect layout outside it by changing its dimensions (potentially leading to overflow or moving other elements on the page).
However, this restriction is not actually sufficient to ensure this "safety". Even if the number of line boxes doesn't change, content moving from one line to another may cause changes in line heights and therefore in the overall height of the block. I think that undermines the intention of the "must not change the number of lines" restriction.
Here's a codepen with a couple of simple examples. Rendering (in Chrome Canary):
As this demonstrates, the revised line-breaking of text-wrap:balance has the potential to make the block either shorter or taller, either of which might have unexpected consequences for the containing layout.
I propose that we should tighten up the restriction on text-wrap-style:balance to say something like "...must not change the number of line boxes the block would contain if text-wrap were set to auto, nor alter its intrinsic size."
Activity
astearns commentedon Apr 9, 2024
The restriction (as I recall) is merely to ensure that the algorithm for balancing lines does not change the number of lines. I think it’s fine for the overall height of the block to vary as in your examples. Do you think there is a benefit to maintaining intrinsic size as well?
jfkthame commentedon Apr 9, 2024
Maybe the number of lines is all that matters? I thought -- perhaps wrongly -- that the idea was to ensure the effect of
balanceis confined to the content within the block, and won't affect layout outside it (so authors can request it in the knowledge that whether or not it's supported, and regardless of the exact algorithm the browser may use, it won't cause other things on the page to shift or break).I'd be interested to know what other people think about this.
(For the record, I did just recently make a change in Gecko's implementation that ensures the intrinsic size of the block does not change. But maybe that's a stricter requirement than we actually want? Here's what the latest Firefox Nightly does with the codepen example:
whereas before the most recent change, it gave the same result as the Chrome screenshot above.)
astearns commentedon Apr 9, 2024
If I were setting the line breaks manually I would prefer the height-constrained result for your first example, and the previous non-height-constrained result for your second example 😁. But that’s just an effect of the particular content, width, and styling, and not something I think we can automate in general.
I look at text-wrap-style: balance as an input to a single composition, communicating a single intent for the block. What happens to the height as that input is flipped doesn’t really matter to me, that’s an entirely different composition. I worry a bit that if we add the height constraint there will be cases where more balanced line breaks would have to be rejected. But I don’t think that worry is enough to reject the idea.
@kojiishi , @fantasai , @frivoal what do you think?
fantasai commentedon Apr 16, 2024
I agree that a height restriction is untenable here. The goal of the restriction was to avoid breaking short amounts of text over more lines than originally, since that can often be counter to the author's desires and also could cause problems if they're making assumptions like "this will not be more than 2 lines" or whatever in the layout. But that really applies mainly to small numbers of lines, 1-6 or so.
We actually discussed internally and we think the restriction should be relaxed from MUST to SHOULD. I might suggest keep it tight for e.g. < 8 lines, not allowed to change the number of lines, for the reasons we originally added the restriction; but beyond that saying it's a SHOULD seems fine to me, and might enable better performance.
astearns commentedon Apr 16, 2024
Typographically I don’t mind reducing changing the number of lines from MUST to SHOULD (there are edge cases where removing a very short last line can achieve better balance). But I don’t think we should allow more than adding or removing one line. There are definitely cases where a headline could be more “balanced” by doubling the number of lines, but that’s not going to be an intended or good result.
Also, would we need to adjust this metric?
Is a comparison of the standard deviation across N-1 or N+1 lines to the standard deviation of N lines still valid?
frivoal commentedon Apr 17, 2024
No strong opinion on allowing +/- 1 line. I do agree that requiring no change in height is likely not a reasonable restriction. Among other things, I think respecting that constrain while taking into account interaction with floats could be a lot more trouble than it is worth.
css-meeting-bot commentedon Apr 24, 2024
The CSS Working Group just discussed
[css-text] Should text-wrap-style:balance be allowed to affect the block height?, and agreed to the following:RESOLVED: Number of lines can change if it's 6+ lines being balanced, and note that this is about line breaks not content height shiftsThe full IRC log of that discussion
<fantasai> jfkthame: Came up as I was fixing a bug<fantasai> jfkthame: Spec requires that text-wrap: balance doesn't change the number of lines
<fantasai> jfkthame: thought an author might expect it doesn't affect the overall size of the block
<fantasai> jfkthame: I wondered if that was a correct expectation, or whether it's OK for it to alter the block height
<florian_irc> q+
<fantasai> jfkthame: currently that's not a constraint in Firefox
<astearns> ack florian_irc
<fantasai> florian_irc: In Firefox, is that constraint generally observed or always? Complicated wrt floats etc.
<fantasai> s/not a/a/
<fantasai> jfkthame: always
<astearns> ack fantasai
<dbaron> fantasai: when we wrote the spec it wasn't about wanting to restrict the height -- it was about the general case of not wanting the 2 line heading to become a 3 line heading because you turned on text-wrap:balance
<dbaron> fantasai: since then it's been brought up about balancing a larger number of lines, e.g., 20-30 or more. At that point you might not care if a line is added/removed if you balance the text.
<dbaron> astearns: we have a current limit at 10, implementations may be more restrictive
<dbaron> fantasai: not required to do more than 10, but can
<florian_irc> q+
<dbaron> fantasai: I don't think we should restrict effects on the block height. Changing the way text wraps can change the height of the lines. Maintaining a stable height wasn't particularly the goal of the feature.
<dbaron> fantasai: Instead, we should say for a small number of lines (e.g., < 8) then the restriction should stay, but for more than that (betwen 6 and 10) the number of lines can change.
<astearns> ack florian_irc
<dbaron> fantasai: Trying not to change it but might shift by 1 or 2 lines. Enables some faster algorithms which might make larger numbers of lines more possible.
<fantasai> florian_irc: agree with fantasai, also curious about firefox
<fantasai> florian_irc: did you implement this way for a specific reason?
<fantasai> jfkthame: it was fallout from fixing a different bug
<fantasai> jfkthame: that ended up with ensuring that the height doesn't change, that wasn't a specific demand
<fantasai> florian_irc: in that case, the current definition is maybe too specific about precisely how much balancing is the right amount
<fantasai> florian_irc: maybe we shouldn't require the the Firefox behavior, but allow some amount of discretion
<fantasai> florian_irc: might want to balance other considerations
<fantasai> astearns: the method to evaluate whether to evaluate whether something is more balanced
<fantasai> astearns: it's not "you must achieve this", but if you hadn't done this then the line breaks you're considering are not more balanced
<fantasai> astearns: seems we could resolve on loosening the requirement on changing number of lines if number of lines balancing is a larger number
<fantasai> astearns: maybe other things fall out from that
<dbaron> (and is it clear that the requirement is about "number of lines" rather than about "height")
<fantasai> florian_irc: if we don't require FF behavior, should make that clear
<dbaron> fantasai: if we change it so the # of lines is possible to change that will be more obvious
<fantasai> astearns: might still be worth clarifying
<fantasai> astearns: proposed that we relax the restriction on changing the number of lines, and clarify it's only about number of line breaks not resulting height
<fantasai> [discussing what's the limit]
<fantasai> PROPOSED: Number of lines can change if it's more than 6-ish lines being balanced
<fantasai> RESOLVED: Number of lines can change if it's 6+ lines being balanced, and note that this is about line breaks not content height shifts
[css-text-4] Loosen requirement about balancing not affecting the lin…