Closed
Bug 26998
Opened 25 years ago
Closed 24 years ago
Temporary bug-24186 fix does not ignore trailing whitespace {ll} {compat}
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: ian, Assigned: dbaron)
References
()
Details
(Keywords: top100)
Attachments
(5 files)
The fix for bug 24186 does not ignore trailing white-space, which means that the rendering of this markup: <p> <font size="1">bla <br> bla <br> bla</font> </p> ...has a gap between the last line and the penultimate one. The long-term fix for bug 24186 would NOT automatically fix this!!! ...because the white-space would have an inherent line-height (it is in an anonymous inline element). On the long term, we will need to make sure that when we ignore the line-height of blocks we also ignore the line-height of inline elements containing only white-space. (Woohoo, another quirk, great.) See this test page: http://www.bath.ac.uk/%7Epy8ieh/m/font-and-line-height.html See also bug 26996.
Assignee | ||
Comment 1•25 years ago
|
||
The third and fourth testcases for http://bugzilla.mozilla.org/showattachment.cgi?attach_id=5077 show that this is a problem for both leading and trailing whitespace. When Kipp wrote the fix for bug 5821, I think he had to do something very similar for leading/trailing whitespace. You might want to look at nsLineLayout::VerticalAlignFrames(PerSpanData* psd). I think the relevant code is the use of pfd->mIsNonEmptyTextFrame.
Assignee | ||
Comment 2•25 years ago
|
||
I'm a bit puzzled by this bug... I may try to figure it out more later.
Comment 3•25 years ago
|
||
Do we know of examples of this causing problems on the Top 100? (It must. There should be plenty of random whitespace all over HTML pages between the element.) If so, this should be nominated for beta1 status.
Assignee | ||
Comment 4•25 years ago
|
||
There are also problems with non-trailing whitespace. For example, see the right column of http://www.w3.org/ (it may only show up with my fixes...).
Assignee | ||
Comment 5•25 years ago
|
||
I have a fix for this one, too, and I still don't understand what's going on with www.w3.org (it's not whitespace that's the problem, and I don't understand the legacy rendering). Could one of my fixes have been too agressive? I'll need to look at www.w3.org with a build without my fixes to compare... See the image http://www.people.fas.harvard.edu/~dbaron/tmp/w3.png for the comparison. On the left, Mozilla with my fixes. On the right, NN 4.7. Anyway, assigning this bug to myself.
Assignee: buster → dbaron
Assignee | ||
Comment 6•25 years ago
|
||
I figured out the problem with www.w3.org. Nav4 seems to behave quirkily in the following way: it applies the min-line-height (!) to LI, DD, and DT elements. I will attach a test case to show this. I guess I should really go through and test all the block-level elements to see if this happens for any others, but I'm not going to do that right now. Instead, I'm going to work on adding yet another quirk into the code (but this is a quirk to sometimes not be quirky...).
Assignee | ||
Comment 7•25 years ago
|
||
Assignee | ||
Comment 8•25 years ago
|
||
It seems this Nav4 quirk (really un-quirk) only applies to the first and last line of LI, DD, and DT elements. However, that produces some awfully silly looking results, and I don't think it's worth doing it exactly that way. I think simply applying min-line-height to LI, DD,and DT, should work.
Assignee | ||
Comment 9•25 years ago
|
||
Assignee | ||
Comment 10•25 years ago
|
||
WinIE5.0, NN 4.6 Win, and NN 4.7 Linux all seem to do the exact same thing: they apply the min line-height on the first line of an LI (whether or not there is a marker) and on the last line of an LI, DT, or DD. I guess I'll have to figure out how to emulate this... I may need a little help...
Assignee | ||
Comment 11•25 years ago
|
||
OK... I've now implemented the quirk emulation needed to make www.w3.org come out properly. (I imagine this quirk was the result of some bug report around NN2, that was perfectly reverse-engineered by MS when making IE...) Quirks mode only, of course.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Assignee | ||
Comment 12•25 years ago
|
||
Fix checked in 2000-02-14 20:26PDT.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M15 → M14
Reporter | ||
Comment 13•25 years ago
|
||
Looks good from here... Nice one David.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 14•25 years ago
|
||
I'm reopening this bug because the fix causes problems on a top100 site, http://www.infobeat.com/ , once my correction for 5821 is in. Apparently the whitespace should not be ignored in all cases. The 4.x algorithm for ignoring whitespace needs to be reverse-engineered more closely. How does IE5 behave? Testcase (from http://www.infobeat.com/ ) to be attached.
Assignee | ||
Comment 15•25 years ago
|
||
Reporter | ||
Comment 16•25 years ago
|
||
Assignee | ||
Comment 17•25 years ago
|
||
Once I fix 5821 the Moz behavior will change to all small gaps rather than all big ones. Note that the small gap was my own edit, for demonstration purposes - I removed some whitespace (the last child of the cell) in one cell.
Assignee | ||
Comment 18•25 years ago
|
||
On bug 25810, attinasi@netscape.com mentioned that Hn elements (I think) may also exhibit some quirky behavior. I need to test this. Marking assigned.
Status: REOPENED → ASSIGNED
Assignee | ||
Updated•25 years ago
|
Target Milestone: M14 → M15
Assignee | ||
Comment 19•25 years ago
|
||
Assignee | ||
Comment 20•25 years ago
|
||
The above testcase shows Hn elements are fine, but PRE needs work. (This bug should really be two separate bugs, and it's my fault, too... Oh well. I think it's better as it is now.)
Assignee | ||
Comment 21•24 years ago
|
||
I checked in the fix for the PRE elements. That means there's only one problem left on this bug, and it's one I don't particularly want to deal with. Unless people complain about the behavior (where we're actually a tiny bit more different from the spec than Nav, although IMO less quirkier, since whitespace doesn't change things drastically), I think it's not really worth fixing. But more on this later...
Assignee | ||
Comment 22•24 years ago
|
||
I'm going to mark this bug fixed because it is mostly fixed. The only remaining problem is that (in quirks mode) whitespace around images is not considered in line-height calculations, whereas in NN 4.x it was. In otherwords [ Key: **ignore** == whitespace here is ignored **consider** == whitespace here is considered ] the Gecko model is: <p> **ignore** <font size="1">Text...</font> **ignore** </p> <p> **ignore** <img src="..."> **ignore** </p> whereas the NN 4.x model is (I think): <p> **ignore** <font size="1">Text...</font> **ignore** </p> <p> **consider** <img src="..."> **consider** </p> The only site I've ever seen depend on this NN 4.x behavior is the old version of http://www.infobeat.com/ . I also think it would be rather difficult to emulate this behavior in the current line layout algorithm. Therefore, I think that part of the bug should be considered WONTFIX. If anyone disagrees, file a separate bug on the issue, and not against me...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 23•24 years ago
|
||
My above comment should be corrected to say "the Gecko quirks mode model is". The Gecko standard mode model is: <p> **consider** <font size="1">Text...</font> **consider** </p> <p> **consider** <img src="..."> **consider** </p>
Comment 24•24 years ago
|
||
Marking verified fixed in the July 11th build.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•