[bramstein]

Internet Explorer actually has this through the (almost standardized) text-justify CSS property. It still doesn't do hyphenation, but Hyphenator.js (http://code.google.com/p/hyphenator/) fills that gap pretty nicely.

Performance isn't a good argument in my opinion. The algorithm isn't that expensive. The most expensive part right now is retrieving all the text metrics, but you would get that a lot cheaper in the browsers rendering engine.

I briefly looked at hacking it into Webkit, but then gave up due to a lack of time.

[aristus]

I also looked into it recently, and Damon from the Gnome project attempted it in 2002 or so. Also Adobe+Google are trying to get it into WebKit. The problem (as far as I can tell) is that people have tried to do it all at once, and pushing such a large thunk of code upstream is very hard.

I suspect that if you take it in pieces: first get a decent hyphenation algo into Pango, then get that into FF and WebKit, then work on the line-breaker, and then get a new CSS rule approved by the W3C... well, maybe you could get it done in 3 or 4 years.

[thezilch]

W3C [...] 3 or 4 years; don't hold your breath.

[ugh]

Last I looked the CSS3 working draft included a hyphenate property.

[jacobolus]

Is Internet Explorer’s justification done for whole paragraphs using a reasonable algorithm, or just line by line?

[bramstein]

It is the whole paragraph as far as I can tell (I haven't seen the internals, just the output.)

[bzbarsky]

One other thing. This algorithm, unless I'm missing something, doesn't handle situations in which the available widths are different for different lines in the paragraph, and in particular in which they available width for a line depends on the precise break positions and vertical alignment results of all the earlier lines in the paragraph. Handling this is required to correctly handle CSS floats. Greedy line-breaking does this by the simple expedient of fully laying out all previous lines in the paragraph before considering the next line.

[bzbarsky]

> The algorithm isn't that expensive.

It's quadratic in length of the paragraph, no? Not a problem for most reasonable text chunks, but browsers have to deal with unreasonable text too. In particular, O(N^2) algorithms in browser layout are generally unacceptable...

[rakingleaves]

But it would only apply when the web page author "opted in" with the appropriate CSS, no? Doesn't seem like it should affect performance on pages that don't use the feature.

[bzbarsky]

If you made it an opt-in, that might be doable... though there would still be the danger of pages cargo-culting into the opt-in.

But at that point you're also asking browsers to maintain two separate line-wrapping codepaths, of which one is not used anywhere to a first approximation. Browser vendors seem to be somewhat resistant to doing that sort of thing.

[glhaynes]

It could maybe be switched off (even if requested) once a paragraph hits a certain threshold size. Of course I suppose that could get complicated as the paragraph gets mutated by JavaScript... you don't want to be turning it on and off all the time.