In my opinion that is the single biggest problem with web typography, and has been for years. Significantly more important than auto hyphenation.
This has been a solved problem for 40 years (or at least 10–15, if we need to worry about fast performance for interactive use on a desktop computer). Should be table stakes for any software rendering long blocks of text.
It might be possible to use Knuth line breaking in specific circumstances, such as when paragraphs have no floats. But not in general.
Can someone hire some grad students to tackle this or something? We are talking about a significant proportion of all reading people do every day, all over the world.
A pocket computer that can do hundreds of billions of arithmetic operations per second should be able to make text as pretty as an apprentice typesetter from 1600.
As suggested by others bad line-breaking has a bad effect on the large reading population.
Also I hope they can do the thing to adjust spaces on the line so all lines look about the same length.
Filed https://github.com/w3c/csswg-drafts/issues/3756 for this.
Regardless, if it is the case the web relies on this, we should just make it explicitly required to do greedy line breaking. Relying on an implication from here isn't great.
Making anything better opt-in sounds all great and well till we end up in this position again whereby we rely on one (or more) browser's unspecified line-breaking algorithm for the "better line-breaking" option. If we specify anything, we probably actually need to specify the algorithm (and given AFAIK there hasn't been notable improvements in decades, that probably isn't the end of the world).
That's what we get when for 20 years W3C and co ignore layout, and instead have designers (who don't know better) use the styling mechanism of CSS and floats as a layout engine.
The only sane layout mechanism for most of those years were tables, which, even though they weren't built for general purpose page layout, they at least had innate layout support for their contents that could be abused.
That was abuse, but far less abuse than using floats for layout, the most idiotic "best practice" the web has seen (and promoted with smugness from ignorant designers to boot).
At least now we have Flex and Grids. It only took 20 years...
2. One could just determine the height of the float ceiling with the greedy algorithm and run the optimization algorithm with that constraint
> It might be possible to use Knuth line breaking in specific circumstances, such as when paragraphs have no floats. But not in general.
If the CSS specification was updated to add vastly improved line-breaking to all text, would it really be that big a deal to add a few new exceptions to go with it? E.g. make floats behave differently when different line-breaking is used.
There's already plenty of cases in CSS of "oh, that doesn't work there because you're using inline/absolute/float/overflow". It's not like the rules are particular minimal or intuitive right now.
For typesetting more broadly, certainly. For making a clean right edge, no.
Sometimes I think this should be the default: definitely the worst typesetting I've seen is in documents produced by people who ignored all the overfull box warnings; even the greedy algorithm of Word etc would be vastly preferable to that.)
So yes they can be used together. In fact the Unicode TeX engines like XeTeX and LuaTeX do so (I don't know how well they follow the Unicode specification intrinsically versus with the support of language-specific packages, but they seem to do the job).
What’s tricky is actually OpenType, because the length of a “word” can vary in complex ways depending on whether or not it is broken - much more complex than simple hyphens.