5 ms·

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

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 https://www.w3.org/TR/CSS2/visuren.html#float-position

jacobolus 8y ago
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.
- pcwalton 8y ago
  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).
  - sjwright 8y ago
    Why not just make this algorithm a non-default option (like hyphenation) and accept that when it's enabled floats may not be optimal?
    - pcwalton 8y ago
      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.
      - galaxyLogic 8y ago
        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.
gsnedders 8y ago
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 https://github.com/w3c/csswg-drafts/issues/3756 for this.
- pcwalton 8y ago
  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.
  - gsnedders 8y ago
    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.
    - pcwalton 8y ago
      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.
      - gsnedders 8y ago
        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).
devit 8y ago
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
- pcwalton 8y ago
  There are quite a few pages that are broken in Servo precisely because it doesn't implement that rule.
seanwilson 8y ago
> 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.
amelius 8y ago
Then the solution could be a compatible float spec, and a way for users to switch it on (and the old spec off).
coldtea 8y ago
What about giving us a bloody <proper-text> tag, in which no float BS applies, and which has all the proper typographic treatments?

jacobolus 8y ago

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.

pcwalton 8y ago
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).
- sjwright 8y ago
  Why not just make this algorithm a non-default option (like hyphenation) and accept that when it's enabled floats may not be optimal?
  - pcwalton 8y ago
    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.
    - galaxyLogic 8y ago
      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.

gsnedders 8y ago

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 https://github.com/w3c/csswg-drafts/issues/3756 for this.

pcwalton 8y ago
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.
- gsnedders 8y ago
  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.
  - pcwalton 8y ago
    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.
    - gsnedders 8y ago
      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).

devit 8y ago

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

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

seanwilson 8y ago

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

amelius 8y ago

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

coldtea 8y ago

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