Hacker News Reader

Comment by pcwalton | Hacker News Reader

This comes up on every thread related to web typography, and the answer as always is that it's not possible in the general case, at least not with the specs as they are today. The biggest problem is that the CSS specification demands that a float be placed as high as possible (CSS 2.1 section 9.5.1, rule 8 [1]). But float ceilings can be anywhere in the middle of a paragraph. By its nature, Knuth line breaking means that any particular unit (word), and therefore any float ceiling, might not be as high as possible. In fact, the only algorithm that can be used in this case to satisfy the spec is the greedy one. Therefore, Knuth line breaking cannot be used on the Web.

It might be possible to use Knuth line breaking in specific circumstances, such as when paragraphs have no floats. But not in general.

[1]: https://www.w3.org/TR/CSS2/visuren.html#float-position

View on HN

There has to be some kind of method that does a better job balancing line widths than the naïve greedy version, and is compatible with whatever requirements browsers are subject to.

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 stated before, the only algorithm that satisfies the constraint that floats must be placed as high as possible is the greedy one (or, to be more precise, any such algorithm must match the output of the greedy one).

Why not just make this algorithm a non-default option (like hyphenation) and accept that when it's enabled floats may not be optimal?

Sure, an opt-in may be possible. But it requires some spec work and isn't something browsers can just do right now. As gsnedders points out, we'd probably have to spec the entire algorithm to avoid causing compatibility problems in the future.

As you suggested if there are no floats there would be no reason to NOT use the better algorithm. I personally don't use floats often and definitely not inside paragraphs.

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.

While I agree a literal reading of CSS 2.1 implies this, I'm not sure it's a deliberate implicature. I definitely don't think it's meant to imply that greedy line breaking must be used (and, IIRC, Prince for example does not).

Filed https://github.com/w3c/csswg-drafts/issues/3756 for this.

You don't think violating that rule would break the Web? I know quite a few Web pages are broken in Servo because it doesn't implement float ceilings inside paragraphs properly.

Ergh. And I presume they rely on the position relative to the containing block (and therefore also on line-height computation and that whole underdefined mess), rather than the position relative to the line box where the float is placed?

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.

I haven't done a comprehensive survey... I just notice it a lot. Mostly it comes up when sites use inline layout as a poor man's flexbox. It might be possible to make better line breaking an opt-in, though.

Yeah, I could see that would be the case that would likely break if it's violated.

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).

>Mostly it comes up when sites use inline layout as a poor man's flexbox

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...

> Therefore, Knuth line breaking cannot be used on the Web.

> 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.

1. That situation is equivalent to the one where the text is different and longer, and generally web pages are designed to layout properly regardless of the content of multiline text sections, so probably not an issue in practice

2. One could just determine the height of the float ceiling with the greedy algorithm and run the optimization algorithm with that constraint

There are quite a few pages that are broken in Servo precisely because it doesn't implement that rule.

What about giving us a bloody <proper-text> tag, in which no float BS applies, and which has all the proper typographic treatments?

Then the solution could be a compatible float spec, and a way for users to switch it on (and the old spec off).

Reply on news.ycombinator.com