Seems to ignore floats in container

[egbit]

If text to be balanced is constrained to smaller width by floating elements, that smaller width appears to be ignored and the text is balanced assuming the full width of the container. So balancing does not work in the presence of floating elements constraining the text.
(FWIW, in my case, I'd be fine if the width available in the first line is used for all subsequent lines rather than adjusting width as floats are cleared and/or new ones are encountered, but that's just a special case.)

[redmunds]

Yes, this is a known limitation. I'm not sure how to even get the constrained width considering obstructions (floating elements) in JS. Let me know if you know how.

[Rycochet]

The only way I can think of it is manually looking through all siblings and children, and any that have a float value make sure there's a cache of their bounding boxes, then anywhere that the horizontal line will intercept a bounding box reduce the width accordingly... Going to be complicated to put that together though - might be worth looking into the exact technique the browsers use to left-align etc text when there are floats...

[egbit]

Ahh... Found a solution, or workaround. Let the browser do the work :-) The key is Block Formatting Context. Floats only have effect within a BFC. Rather than figure out how to search the DOM for the extent of the BFC and recompute as the browser does, turns out I just have to make sure the element containing the text I need to balance establishes its own BFC, separate from the one where the float exists. That way the element, by W3C definition, cannot overlap floated elements of another (eg. containing) BFC, so has its width constrained not to overlap them, and balance-text sees the correct width. There are many ways to establish BFC, the one I went with which worked for my case is overflow hidden: .balance-text { text-wrap:balanced; overflow:hidden; }. Now block elements I try to balance have the expected constrained width, and balance nicely!

This did have an unfortunate side-effect of hiding the list bullets where I was doing <li class="balance-text">some text</li>, which I fixed by using <li><span class="balance-text">some text</span></li> instead. Otherwise, seems to work quite fine, yeah!

[egbit]

Looking into this a bit more, this solution seems to work with display:inline elements but not display:block or inline-block elements. So the trick of applying balance-text to an added span is needed in other places too that are constrained by floated elements.

[redmunds]

Thanks for the detailed followup!

[redmunds]

Also, see discussion of flexbox case in #51

[fregante]

The flexbox case is different; there the text affects its container's size. It only applies to floats if the floated element needs balance-text.

In this case, like also with CSS shapes, the algorithm would need to change to consider different line box widths. A way to do that would be to wrap each line in a <div> and calculate its size. Or insert two empty divs above and below the line, and get the shortest one: