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?

Maybe the number of lines is all that matters? I thought -- perhaps wrongly -- that the idea was to ensure the effect of balance is 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.)

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?

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.

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?

Line boxes are balanced when the standard deviation from the average [inline-size] of the remaining space in each line box is reduced over the block (including lines that end in a forced break).

Is a comparison of the standard deviation across N-1 or N+1 lines to the standard deviation of N lines still valid?

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.

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 shifts