Last Comment Bug 26998 - Temporary bug-24186 fix does not ignore trailing whitespace {ll} {compat}
: Temporary bug-24186 fix does not ignore trailing whitespace {ll} {compat}
Status: VERIFIED FIXED
: top100
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal (vote)
: M15
Assigned To: David Baron :dbaron: ⌚️UTC-10
: Chris Petersen
: Jet Villegas (:jet)
Mentors:
http://www.bath.ac.uk/%7Epy8ieh/inter...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-08 12:51 PST by Hixie (not reading bugmail)
Modified: 2000-07-13 15:24 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase showing Nav4's behavior (5.37 KB, text/html)
2000-02-11 06:31 PST, David Baron :dbaron: ⌚️UTC-10
no flags Details
additional testcase (best used with page narrow) (2.63 KB, text/html)
2000-02-11 06:50 PST, David Baron :dbaron: ⌚️UTC-10
no flags Details
testcase from www.infobeat.com (3.74 KB, text/html)
2000-02-18 18:31 PST, David Baron :dbaron: ⌚️UTC-10
no flags Details
Screenshot of Win32 IE5, Win32 Nav4 and Win32 Moz showing attachment 5456. (59.05 KB, image/gif)
2000-02-18 19:08 PST, Hixie (not reading bugmail)
no flags Details
more thorough version of attachment 5159 (6.79 KB, text/html)
2000-02-26 11:26 PST, David Baron :dbaron: ⌚️UTC-10
no flags Details

Description Hixie (not reading bugmail) 2000-02-08 12:51:52 PST
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.
Comment 1 David Baron :dbaron: ⌚️UTC-10 2000-02-08 13:17:03 PST
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.
Comment 2 David Baron :dbaron: ⌚️UTC-10 2000-02-08 20:31:15 PST
I'm a bit puzzled by this bug... I may try to figure it out more later.
Comment 3 ekrock's old account (dead) 2000-02-09 17:03:38 PST
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.
Comment 4 David Baron :dbaron: ⌚️UTC-10 2000-02-10 17:54:30 PST
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...).
Comment 5 David Baron :dbaron: ⌚️UTC-10 2000-02-10 19:14:22 PST
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.
Comment 6 David Baron :dbaron: ⌚️UTC-10 2000-02-11 06:29:41 PST
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...).
Comment 7 David Baron :dbaron: ⌚️UTC-10 2000-02-11 06:31:18 PST
Created attachment 5158 [details]
testcase showing Nav4's behavior
Comment 8 David Baron :dbaron: ⌚️UTC-10 2000-02-11 06:48:56 PST
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.
Comment 9 David Baron :dbaron: ⌚️UTC-10 2000-02-11 06:50:46 PST
Created attachment 5159 [details]
additional testcase (best used with page narrow)
Comment 10 David Baron :dbaron: ⌚️UTC-10 2000-02-11 10:19:27 PST
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...
Comment 11 David Baron :dbaron: ⌚️UTC-10 2000-02-11 18:05:04 PST
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.

Comment 12 David Baron :dbaron: ⌚️UTC-10 2000-02-14 20:58:58 PST
Fix checked in 2000-02-14 20:26PDT.
Comment 13 Hixie (not reading bugmail) 2000-02-15 14:50:44 PST
Looks good from here... Nice one David.
Comment 14 David Baron :dbaron: ⌚️UTC-10 2000-02-18 18:27:31 PST
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.
Comment 15 David Baron :dbaron: ⌚️UTC-10 2000-02-18 18:31:34 PST
Created attachment 5456 [details]
testcase from www.infobeat.com
Comment 16 Hixie (not reading bugmail) 2000-02-18 19:08:06 PST
Created attachment 5461 [details]
Screenshot of Win32 IE5, Win32 Nav4 and Win32 Moz showing attachment 5456 [details].
Comment 17 David Baron :dbaron: ⌚️UTC-10 2000-02-18 19:12:42 PST
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.
Comment 18 David Baron :dbaron: ⌚️UTC-10 2000-02-21 10:32:36 PST
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.
Comment 19 David Baron :dbaron: ⌚️UTC-10 2000-02-26 11:26:17 PST
Created attachment 5800 [details]
more thorough version of attachment 5159 [details]
Comment 20 David Baron :dbaron: ⌚️UTC-10 2000-02-26 11:27:56 PST
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.)
Comment 21 David Baron :dbaron: ⌚️UTC-10 2000-03-15 18:24:21 PST
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...
Comment 22 David Baron :dbaron: ⌚️UTC-10 2000-03-21 20:43:16 PST
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...
Comment 23 David Baron :dbaron: ⌚️UTC-10 2000-03-21 20:44:48 PST
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 Chris Petersen 2000-07-13 15:24:21 PDT
Marking verified fixed in the July 11th build.

Note You need to log in before you can comment on or make changes to this bug.