13097 - [QUIRKS][INLINE-V][WHITESPACE]should be space between lines containing images

Status: VERIFIED WONTFIX

(Core :: Layout, defect, P3)

Description

[karnaze (gone)]

Nav 4.6 and pevious versions of Gecko (before bug 5821 was fixed) put space
between the raptors in the example below.

<TABLE border="1" width="100">
 <TR>
  <td bgcolor="#CCCC99">
   <IMG BORDER="0" SRC="raptor.jpg" WIDTH="100" HEIGHT="100">
   <IMG SRC="raptor.jpg"
    height=30 width=100 BORDER="0">
  </TD>
 </TR>
</table>

Comment 1

[Hixie (not reading bugmail)]

We are not putting spaces in one, very specific case: When the line wraps
because the container is the same size or smaller than the images. I do not
know why this is. It works in all other cases. See this detailed test case:
   http://www.bath.ac.uk/~py8ieh/a/internet/projects/mozilla/compatimg.html

Whitespace seems to have an important role in this. Fiddling about with the
test case putting different whitespace before/after each <img> and at the
start/end of lines causes differences in the spacing.

Comment 2

[kipp]

In previous releases, the empty white-space that follows each image would be
placed on the same line as the image affecting the total line-height (because of
the descent of the font of the text). In gecko, the empty white-space that
follows ends up at the start of the subsequent line (because it doesn't fit
horizontally) and is compressed away into nothingness.

There are other places where this whitespace treatment of nav4.x manifests
itself into layout problems (e.g. 4803)

Comment 3

[Hixie (not reading bugmail)]

Note that the behaviour is currently wrong in both standard AND compat modes.

Here is a version of this test with a STANDARD doctype:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/compatimg-std.html
..and here is a version of this test with a QUIRKY doctype:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/compatimg.html

The first should (AFAICT) have the same amount of spacing between every stacked
picture, namely, a few pixels. Currently, a buggy compatability mode is being
triggered that is non-standards compliant and non-quirk-compatible.

Comment 4

[kipp]

can you come up with a test that works in nav4 so that I can compare legacy
behavior with it? I don't happen to have a version of IE for linux...

In addition, do we really care?

Comment 5

[Hixie (not reading bugmail)]

In standard mode, yeah we care!

Sorry, Nav 4.x is too broken for a test case. But I'll post some screenshots
of IE's and Gecko's behaviour with the compat version of the test.

Comment 6

[Hixie (not reading bugmail)]

Current results are as follows.

  STANDARD MODE
  We pass all the tests except for the last TABLE test in
    http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/compatimg-std.html

  The markup for this test is:

   <table width="100"> <tr> <td>
      <img src="../../../media/sample.gif" width="100" height="100"> <br>
      <img src="../../../media/sample.gif" width="100" height="100">
   </td> </tr> </table>

  We do not appear to be compressing the whitespace at the start/end of the
  lines (when in the table, anyway), which ends up adding an extra line of
  whitespace between the images.

  COMPAT MODE
  We are currently showing non-backwards compatible and non-standard
  effects on the first test, in the TABLE (right hand side). The second test
  follows backwards compatability, then third test does IE-style rendering
  (in this case standards compliant) inside the DIV, and Nav4-style rendering
  (in this case non-standards compliant) inside the TABLE. (This is like for
  the standard-mode version of the test.)

Screenshots of IE5 and Gecko behaviour for all three *COMPATABILITY* TESTS
follow. Each screenshot includes a textual description of what IE5 does (i.e.
the compat mode behaviour expected).

Note that Nav4 differs (I think...) to IE5 in the last test, in that it renders
the test with a big gap between the lines for both the DIV and TABLE versions
of the test. This is incorrect (see above).

Since we _have_ compat-mode logic here anyway, we should either fix it to be
consistent with legacy browsers, or yank it altogether. As for the standards
mode tests, we want to be passing those regardless.

Comment 7

[Hixie (not reading bugmail)]

Attachment: Screenshot: IE5, test 1

Comment 8

[Hixie (not reading bugmail)]

Attachment: Screenshot: IE5, test 2

Comment 9

[Hixie (not reading bugmail)]

Attachment: Screenshot: IE5, test 3

Comment 10

[Hixie (not reading bugmail)]

Attachment: Screenshot: Gecko 1999110313 , test 1

Comment 11

[Hixie (not reading bugmail)]

Attachment: Screenshot: Gecko 1999110313 , test 2

Comment 12

[Hixie (not reading bugmail)]

Attachment: Screenshot: Gecko 1999110313 , test 3

Comment 13

[leger]

Updating to default Layout Assignee...kipp no longer with us :-(

Comment 14

[troy]

Why are you re-reassing layout bugs? Do NOT touch layout bugs.

The bugs are assigned to Kipp so they can stay neatly organized until we have a
new owner for the block/inline code.

Comment 15

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 16

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 17

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 18

[buster]

David, this is closely related to the other 2 bugs I just re-assigned to you.

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This one is a bit different from the other two, but I'll have a look (though 
not necessarily right now)...

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is related to my last pair of comments in bug 26998.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'd actually like to see more testcases here - I see 30 possible cases (well, 60 
if you count standards/compat as separate cases), and Ian's tests cover 6 (12) 
of those.  We should test:
 * (2) table, div
 * (3) containing width narrower than image, same as image, wider than image
 * (5) wrapped break with whitespace, BR with no whitespace, BR with w.s. 
before, BR with w.s. after, BR with w.s. on both sides

Are any of the differences in the current testcases due to the DIV's width being 
110px and the TABLE's being 100px?  (Also, table's width may (I don't 
remember) refer to outer width, so it's better to drop the borders.)

Ian, do you want to add these tests, or should I?  (Or is it a priority now???)

Comment 22

[Hixie (not reading bugmail)]

David: I can do a script to generate these if you like.

Comment 23

[Hixie (not reading bugmail)]

Ok, I've done it.

The 60 tests are here:
 http://www.bath.ac.uk/%7Epy8ieh/cgi/development/tests/linemodel1?mode=standard
 http://www.bath.ac.uk/%7Epy8ieh/cgi/development/tests/linemodel1?mode=quirky

Tell me how to improve them.

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ian - It would be an improvement if the part with the DIVs actually tested what 
it says it does. :-)  All the image are separated by nothing.

The other useful thing would be an explanation of the rules 4.x follows.  I 
suspect it is something like that a space between images or a space beteen an 
image and the end of the line is significant for the inline box model.  
(Remember the remaining issues that I marked WONTFIX in bug 26998.  Maybe it's 
time to fix them too...)

Pushing to M19.  This isn't for beta2, and isn't the first thing I'll be doing 
after it goes out, either.

Comment 25

[Hixie (not reading bugmail)]

David: Script fixed. (three character fix...)

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Anybody object if I future this?  Anybody want to fix it instead?  These things
are a pain...

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Giving this to buster since I have no plans to look at this in the next few
months, at least.

Comment 28

[buster]

suggest beta3-   fairly minor layout glitch, moderately high risk to fix

Comment 29

[karnaze (gone)]

Marking nsbeta3-.

Comment 30

[Hixie (not reading bugmail)]

Broke out the standards compliant part of this bug as bug 53985.

Marking the rest of this WONTFIX.

The rest of this is a compatability issue, but since we are not fixing it for 
this release, web authors will have to write their markup to work around the 
way we render it regardless of whether we 'fix' it in the future or not. Thus, 
fixing it in the future is a waste of our time.

Comment 31

[Christine Hoffman]

Verified WONTFIX.