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

VERIFIED WONTFIX

Status

()

Core
Layout
P3
normal
VERIFIED WONTFIX
19 years ago
18 years ago

People

(Reporter: karnaze (gone), Assigned: buster)

Tracking

({compat, css1, testcase})

Trunk
Future
x86
Windows NT
compat, css1, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nsbeta3-, URL)

Attachments

(6 attachments)

(Reporter)

Description

19 years ago
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>

Updated

19 years ago
Status: NEW → ASSIGNED
Summary: no space between lines containing images → {compat} no space between lines containing images
Target Milestone: M12
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.

Updated

19 years ago
Target Milestone: M12 → M15

Comment 2

19 years ago
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)
Summary: {compat} no space between lines containing images → {css1} {compat} no space between lines containing images
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

19 years ago
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?
Whiteboard: [TESTCASE] → [TESTCASE] (py8ieh:making screenshots...)
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.
Whiteboard: [TESTCASE] (py8ieh:making screenshots...) → [TESTCASE]
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.
Created attachment 2655 [details]
Screenshot: IE5, test 1
Created attachment 2656 [details]
Screenshot: IE5, test 2
Created attachment 2657 [details]
Screenshot: IE5, test 3
Created attachment 2658 [details]
Screenshot: Gecko 1999110313 , test 1
Created attachment 2659 [details]
Screenshot: Gecko 1999110313 , test 2
Created attachment 2660 [details]
Screenshot: Gecko 1999110313 , test 3

Updated

19 years ago
QA Contact: petersen → chrisd

Comment 13

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

Comment 14

19 years ago
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.
(Assignee)

Updated

19 years ago
Summary: {css1} {compat} no space between lines containing images → {css1} {compat} [BLOCK] no space between lines containing images
Keywords: css1
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...
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase

Updated

19 years ago
Summary: {css1} {compat} [BLOCK] no space between lines containing images → {compat} [BLOCK] no space between lines containing images
Whiteboard: [TESTCASE]
(Assignee)

Comment 17

19 years ago
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
(Assignee)

Comment 18

18 years ago
David, this is closely related to the other 2 bugs I just re-assigned to you.
Assignee: buster → dbaron
This one is a bit different from the other two, but I'll have a look (though 
not necessarily right now)...
This is related to my last pair of comments in bug 26998.
Keywords: 4xp
Summary: {compat} [BLOCK] no space between lines containing images → {compat} [INLINE][WHITESPACE] should be space between lines containing images
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???)
David: I can do a script to generate these if you like.
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.
Keywords: 4xp → compat
Summary: {compat} [INLINE][WHITESPACE] should be space between lines containing images → should be space between lines containing images [INLINE] [WHITESPACE]
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.
Target Milestone: M17 → M19
David: Script fixed. (three character fix...)

Updated

18 years ago
Keywords: nsbeta3, relnote2
Anybody object if I future this?  Anybody want to fix it instead?  These things
are a pain...
Target Milestone: M19 → Future
Giving this to buster since I have no plans to look at this in the next few
months, at least.
Assignee: dbaron → buster
Summary: should be space between lines containing images [INLINE] [WHITESPACE] → [QUIRKS][INLINE-V][WHITESPACE]should be space between lines containing images
(Assignee)

Comment 28

18 years ago
suggest beta3-   fairly minor layout glitch, moderately high risk to fix
Status: NEW → ASSIGNED
(Reporter)

Comment 29

18 years ago
Marking nsbeta3-.
Whiteboard: nsbeta3-
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 31

18 years ago
Verified WONTFIX. 
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.