Make white-space work on inlines

VERIFIED FIXED in mozilla1.6beta

Status

()

Core
Layout: Block and Inline
P1
normal
VERIFIED FIXED
14 years ago
9 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: dbaron)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
mozilla1.6beta
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [patch], URL)

Attachments

(1 attachment, 5 obsolete attachments)

(Reporter)

Description

14 years ago
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
(Assignee)

Updated

14 years ago
Blocks: 184703
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.4alpha

Updated

14 years ago
Keywords: testcase
(Assignee)

Comment 1

14 years ago
Created attachment 119252 [details] [diff] [review]
the beginning of a patch

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

Comment 2

14 years ago
Created attachment 135094 [details] [diff] [review]
just the nsIFrame::IsEmpty cleanup

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

Updated

14 years ago
Whiteboard: [patch]
Target Milestone: mozilla1.4alpha → mozilla1.6beta
(Assignee)

Updated

14 years ago
Attachment #135094 - Flags: superreview?(roc)
Attachment #135094 - Flags: review?(roc)
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?
Attachment #135094 - Flags: superreview?(roc)
Attachment #135094 - Flags: superreview+
Attachment #135094 - Flags: review?(roc)
Attachment #135094 - Flags: review+
(Assignee)

Comment 4

14 years ago
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.
Attachment #135094 - Attachment is obsolete: true
> "Text frames containing only whitespace that does not contribute to the height
> of the line should return false."

Shouldn't that be "true"?
(Assignee)

Comment 6

14 years ago
Created attachment 135225 [details] [diff] [review]
remove BRS_NOWRAP

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

Updated

14 years ago
Attachment #135225 - Flags: superreview?(roc)
Attachment #135225 - Flags: review?(roc)
(Assignee)

Comment 7

14 years ago
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
Attachment #135225 - Flags: superreview?(roc)
Attachment #135225 - Flags: superreview+
Attachment #135225 - Flags: review?(roc)
Attachment #135225 - Flags: review+
(Assignee)

Comment 9

14 years ago
Created attachment 135263 [details] [diff] [review]
nsLineLayout changes merged to trunk
(Assignee)

Comment 10

14 years ago
Comment on attachment 135225 [details] [diff] [review]
remove BRS_NOWRAP

Fix checked in to trunk, 2003-11-11 11:24 -0800.
Attachment #135225 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #119252 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Blocks: 225946
This may have caused the regression in bug 232540.
More likely it just exposed an existing bug :-)

Updated

13 years ago
Blocks: 178671
(Assignee)

Comment 13

13 years ago
Created attachment 167095 [details] [diff] [review]
nsLineLayout changes merged to trunk
Attachment #135263 - Attachment is obsolete: true
Blocks: 277771
(Assignee)

Updated

12 years ago
Blocks: 101565

Comment 14

12 years ago
*** Bug 312315 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 15

11 years ago
Created attachment 248028 [details] [diff] [review]
nsLineLayout changes to make white-space apply to inlines

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.
Attachment #167095 - Attachment is obsolete: true
Attachment #248028 - Flags: superreview?(roc)
Attachment #248028 - Flags: review?(roc)
(Assignee)

Comment 16

11 years ago
(It's the CanPlaceFrame changes that I think deserve some scrutiny.)
(Assignee)

Updated

11 years ago
Depends on: 300030, 343445
(Assignee)

Comment 17

11 years ago
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.
(Assignee)

Comment 18

11 years ago
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.
(Assignee)

Comment 19

11 years ago
(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.)
(Reporter)

Comment 20

11 years ago
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?
(Assignee)

Comment 22

11 years ago
Ah, ok, it can wait.
(Assignee)

Updated

11 years ago
Attachment #248028 - Flags: superreview?(roc)
Attachment #248028 - Flags: review?(roc)

Updated

11 years ago
Blocks: 332554
(Assignee)

Updated

10 years ago
Flags: blocking1.9?
(Assignee)

Updated

10 years ago
Blocks: 261081
(Assignee)

Updated

10 years ago
Flags: blocking1.9? → blocking1.9+
I think this works fine now thanks to new-textframe.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Depends on: 393096
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.