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)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: top100)

Attachments

(5 files)

testcase showing Nav4's behavior
5.37 KB, text/html
Details
additional testcase (best used with page narrow)
2.63 KB, text/html
Details
testcase from www.infobeat.com
3.74 KB, text/html
Details
Screenshot of Win32 IE5, Win32 Nav4 and Win32 Moz showing attachment 5456.
59.05 KB, image/gif
Details
more thorough version of attachment 5159
6.79 KB, text/html
Details 
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.
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.
I'm a bit puzzled by this bug... I may try to figure it out more later.
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.
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...).
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
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...).
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.
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...
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.
Status: NEW → ASSIGNED
Target Milestone: M15
Fix checked in 2000-02-14 20:26PDT.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M15 → M14
Looks good from here... Nice one David.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Keywords: top100
Resolution: FIXED → ---
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.
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
Target Milestone: M14 → M15
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.)

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

Attachment

General

Creator:
Created:
Updated:
Size: