Temporary bug-24186 fix does not ignore trailing whitespace {ll} {compat}




18 years ago
17 years ago


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




Firefox Tracking Flags

(Not tracked)




(5 attachments)



18 years ago
The fix for bug 24186 does not ignore trailing white-space, which means that
the rendering of this markup:

     <font size="1">bla <br> bla <br> bla</font>

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

See also bug 26996.

Comment 1

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

Comment 2

18 years ago
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.

Comment 4

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

Comment 5

18 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

Comment 6

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

Comment 7

18 years ago
Created attachment 5158 [details]
testcase showing Nav4's behavior

Comment 8

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

Comment 9

18 years ago
Created attachment 5159 [details]
additional testcase (best used with page narrow)

Comment 10

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

Comment 11

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



18 years ago
Target Milestone: M15

Comment 12

18 years ago
Fix checked in 2000-02-14 20:26PDT.
Last Resolved: 18 years ago
Resolution: --- → FIXED
Target Milestone: M15 → M14

Comment 13

18 years ago
Looks good from here... Nice one David.

Comment 14

18 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.
Keywords: top100
Resolution: FIXED → ---

Comment 15

18 years ago
Created attachment 5456 [details]
testcase from www.infobeat.com

Comment 16

18 years ago
Created attachment 5461 [details]
Screenshot of Win32 IE5, Win32 Nav4 and Win32 Moz showing attachment 5456 [details].

Comment 17

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

Comment 18

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


18 years ago
Target Milestone: M14 → M15

Comment 19

18 years ago
Created attachment 5800 [details]
more thorough version of attachment 5159 [details]

Comment 20

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

Comment 21

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

Comment 22

18 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

[ 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...
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 23

18 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

17 years ago
Marking verified fixed in the July 11th build.
You need to log in before you can comment on or make changes to this bug.