For CSS2.1 we need to make white-space work on all elements, even inlines. Testcase: http://www.hixie.ch/tests/adhoc/css/text/white-space/mixed/001.html

This is the beginning of a patch. The "max-element-size" calculation for within lines, however, needs to be completely rewritten. (It's currently in nsLineLayout::VerticalAlignLine.) The current code is just all wrong, and this makes it slightly worse by not considering 'white-space' much.

Considering the state of the current code (partially following 'white-space' on inlines), this will probably slightly improve our behavior, and it's certainly movement in the right direction.

Comment on attachment 135094 [details] [diff] [review] just the nsIFrame::IsEmpty cleanup Nice. Is the comment in nsIFrame correct? "logically empty, i.e., whether the * layout would be the same whether or not the frame is present." A whitespace-only text frame with collapsing whitespace can still affect layout because it collapses to one space. Right?

Comment on attachment 135094 [details] [diff] [review] just the nsIFrame::IsEmpty cleanup Checked in, 2003-11-10 15:36 -0800, with improved comment in nsIFrame.h.

> "Text frames containing only whitespace that does not contribute to the height > of the line should return false." Shouldn't that be "true"?

This just removes an invalid optimization once 'white-space' applies to inlines (which we already partly do). (Actually, I think I thought the whole larger optimization is invalid. I should probably remember what the issue was.)

This just leaves the nsLineLayout changes from the original patch, which are the ones that need work...

Comment on attachment 135225 [details] [diff] [review] remove BRS_NOWRAP okey doke

Comment on attachment 135225 [details] [diff] [review] remove BRS_NOWRAP Fix checked in to trunk, 2003-11-11 11:24 -0800.

This may have caused the regression in bug 232540.

More likely it just exposed an existing bug :-)

*** Bug 312315 has been marked as a duplicate of this bug. ***

There are still a bunch of trimming/collapsing issues before we pass Hixie's test, but this makes the result at least *resemble* the expected form of output. I thought this through a bit, but I'd appreciate if you could take a good look at this to make sure it also makes sense to you.

(It's the CanPlaceFrame changes that I think deserve some scrutiny.)

I think substantial parts of Hixie's test are invalid, though. I'll refer in this description to the parts of the test as being lines (1) through (8), where the word PASS appears on lines (4) (top) through (8) (bottom). I think the test is invalid for the following reasons: * It requires that the user-agent break at one point where a break is forbidden. In particular, this is the break that is supposed to separate lines (4) and (5). Both Mozilla and Opera do not break here. I believe this break is forbidden because at this break point (between the "x" before it and the "x" after it) there are two spaces: the first (in an inner span) has 'white-space: nowrap'; the second (in an outer span that is a descendant of the div) has 'white-space: normal'. According to CSS2.1, section 16.6.1, first ordered list, item 4.2, this second space (with 'white-space: normal') must be ignored. Therefore there is only a space with 'white-space:nowrap', and that doesn't introduce a break opportunity. * Our other problem with the test is that we interpret the spaces with 'white-space:normal' preceding spaces with 'white-space:pre' in line (5) as breaking opportunities. The latter are supposed to be treated as non-breaking spaces. I need to have another look at UAX #14 and investigate Web-compatibility issues related to changing our handling of non-breaking spaces, or look into potentially treating these spaces as non-breaking spaces were supposed to be treated and not treating actual non-breaking spaces that way. In any case, I don't think the behavior here is defined by CSS.

Note that I think Opera 9's behavior on this test is probably the most correct behavior, although other behaviors may be valid. I haven't checked its handling of the early part of line (5) carefully (i.e., I haven't counted spaces), though.

(Note that I have a few additional changes in my tree in addition to the patch above -- I'm including those when referencing our behavior. I need to figure out if any of them are actually helping anything -- perhaps even something not in this test -- once I land the patch above and the patch in bug 363232.)

I don't think a space being collapsed away should reduce its ability to introduce line breaking opportunities. In particular, I think two runs of spaces in <nobr> elements with a normal space in between them should be able to split across two lines. No?

In the new textframe code I'm moving linebreak opportunity calculation to textrun construction time and making it work paragraph-at-a-time, and I'm handling white-space there at the same time because the linebreaking algorithm interacts with CSS 'white-space' in messy ways. In particular, line breaks due to whitespace have to be distinguished from line breaks not due to whitespace because they are controlled by CSS properties on different elements. E.g. given <span class="A"><span class="B">X</span>Y</span> If X and Y are a breakable CJK pair then A's white-space property governs, but if X is whitespace then B's white-space property governs. Now that I'm merging in the reflow branch changes, I think I'll also move whitespace trimming to that phase, out of reflow, because min-width and pref-width calculation need that information too. That would make it easy to code up whatever policy we want here. So do we really need to solve this bug now, or can it wait for new textframe?

Ah, ok, it can wait.

I think this works fine now thanks to new-textframe.

I'm going to call this verified, with a note that the testcase in the URL field no longer displays properly due to bug 393096. See bug 393096 comment 27 through 33. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050704 Minefield/3.0pre