- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Thu, 31 Jan 2013 13:00:29 +1100
- To: www-style@w3.org
> This algorithm does not affect the width or height of the containing > element as this may affect rendering of the rest of the document. The > resulting text will always wrap to same number of lines as original text > so height doesn't change. I see that David has already pointed this out before I finished writing this message, but I might as well still give the example I'd written for the mix-of-heights-or-baselines case: changing the line breaks can change whether two tall elements are on the same line or different lines. However, I don't see that it's of absolute importance that text-wrap:balance have no effect on height. Giving a different answer to the question about pagination or column balancing: text-wrap:balance should have no effect on width of the column. Even if different iterations of column balancing somehow result in different heights of text-wrap:balance text (as might happen due to floats), this is something that column balancing has to deal with whether or not text-wrap:balance is present. Incidentally, column balancing and line balancing are very similar problems; I imagine that both the pitfalls and solutions are similar. > We'd need to decide whether shrink-to-fit containers would respond to the > possibly shorter line lengths. Can you say a bit more about the cases you're thinking of here? I'm thinking that text-wrap:balance shouldn't affect that, but it may well be that I'm not thinking of the same cases you are. Currently, the width of a float or inline-block isn't affected by wastage at the ends of lines. (Arguably the preferred-width or even minimum-width cases are exceptions, but line balancing wouldn't affect the width in those cases anyway.) As to whether we should change this for the case that line balancing does effect, namely that where shrink-to-fit is the available width, it's not clear that making the float a bit narrower than available width is in general an improvement anyway. Sometimes it would be better, sometimes worse. The analysis for auto-table-layout table cells is slightly different. To start with, their width isn't normatively defined. One could say much more about tables, but let's just say that whether it's desirable to calculate column widths based on something like the balanced width of the content doesn't seem to depend much on whether the content really does have text-wrap:balance. In all of these cases, one would occasionally want the container width to shrink to reduce wastage at the ends of lines even without line balancing, and in each case one would sometimes not want to do so even with line balancing. OTOH, text-wrap:balance does make it more common to want shrink-to-actual-width in each case. Still, my feeling is that it would be a separate property proposal, one that just happens to be made a bit more compelling by the existence of text-wrap:balance. pjrm.
Received on Thursday, 31 January 2013 02:00:58 UTC