15933 - Table cells do not become 1 px width and height

Status: VERIFIED INVALID

(Core :: Layout: Tables, defect, P3)

Description

[Masatoshi Kimura [:emk]]

Steps to reproduce:
1. Launch apprunner.
2. Go to the following attachment.

Expected result:
Table cells should be 1px width and height.
Nav4 and IE displays as expected.

Actual result:
In quirks mode, table cells have the 3px width (this is not compatible with
Nav4/IE).
In standard mode, table cells have the 6px height even if 'line-height' is
zero.

I'm using [1999100708] build apprunner on WinNT4 (SP5).

Comment 1

[Masatoshi Kimura [:emk]]

Attachment: Image used the following testcase

Comment 2

[Masatoshi Kimura [:emk]]

Attachment: Testcase for quirks mode

Comment 3

[Masatoshi Kimura [:emk]]

Attachment: Testcase for standard mode

Comment 4

[karnaze (gone)]

The Nav Quirks attachement now looks like Nav. The Standard attachment looks ok,
but I didn't see that it was 6 pixels tall.

Comment 5

[Masatoshi Kimura [:emk]]

Hmmm... In standard mode, it's still 6 px tall on my environment.
I'm using [1999101808] mozilla on WinNT4 (SP5).

Comment 6

[Masatoshi Kimura [:emk]]

Attachment: Screenshort for attachment 2056

Comment 7

[karnaze (gone)]

You are right (or at least it is somewhere around 6 pixels). I was basing my
comments on a page which was a local copy of attachment #3 [details] [diff] [review] (as well as a local
copy of showattachment.cgi).

Kipp, there appears to be a difference when this page is local versus not. The
last table in tests/table/bugs/bug15933.html displays ok in standard mode, but
the identical page (attachement #3) is different and causing the problem; the 1
pixel high image is asking to be higher than that.

Original attachment

  TO::Rfl en 0214EEE0 rea=0 av=(8940,UC) comp=(8910,UC)
    T::Rfl en 0214EE40 rea=0 av=(8940,UC) comp=(8940,UC)
      TRG::Rfl 0214E900 rea=0 av=(UC,UC) comp=(UC,UC)
        TR::Rfl en 0214E3A0 rea=0 av=(UC,UC) comp=(UC,UC)
          TC::Rfl 0214FE00 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl en 0214FD70 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl ex 0214FD70 des=(15,83) maxElem=(15,15)
          TC::Rfl ex 0214FE00 des=(45,113) maxElem=(45,45)
        TR::Rfl ex 0214E3A0 des=(45,113) maxElem=(45,45)
      TRG::Rfl ex 0214E900 des=(UC,113) maxElem=(45,45)
      TRG::Rfl 0214E900 rea=2 av=(45,UC) comp=(45,UC)
        TR::Rfl en 0214E3A0 rea=2 av=(45,UC) comp=(45,UC)
          TC::Rfl 0214FE00 rea=2 av=(45,UC) comp=(15,UC)
            Area::Rfl en 0214FD70 rea=2 av=(15,UC) comp=(15,UC)
            Area::Rfl ex 0214FD70 des=(15,83)
          TC::Rfl ex 0214FE00 des=(45,113)
        TR::Rfl ex 0214E3A0 des=(45,113)
      TRG::Rfl ex 0214E900 des=(45,113)
    T::Rfl ex 0214EE40 des=(75,143)
  TO::Rfl ex 0214EEE0 des=(75,143)

Attachment brought to local file system

  TO::Rfl en 01C79060 rea=0 av=(8940,UC) comp=(8910,UC)
    T::Rfl en 01C7AE60 rea=0 av=(8940,UC) comp=(8940,UC)
      TRG::Rfl 01C7A890 rea=0 av=(UC,UC) comp=(UC,UC)
        TR::Rfl en 01C7A330 rea=0 av=(UC,UC) comp=(UC,UC)
          TC::Rfl 01C7BDB0 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl en 01C7BD20 rea=0 av=(UC,UC) comp=(UC,UC)
            Area::Rfl ex 01C7BD20 des=(15,15) maxElem=(15,15)
          TC::Rfl ex 01C7BDB0 des=(45,45) maxElem=(45,45)
        TR::Rfl ex 01C7A330 des=(45,45) maxElem=(45,45)
      TRG::Rfl ex 01C7A890 des=(UC,45) maxElem=(45,45)
      TRG::Rfl 01C7A890 rea=2 av=(45,UC) comp=(45,UC)
        TR::Rfl en 01C7A330 rea=2 av=(45,UC) comp=(45,UC)
          TC::Rfl 01C7BDB0 rea=2 av=(45,UC) comp=(15,UC)
            Area::Rfl en 01C7BD20 rea=2 av=(15,UC) comp=(15,UC)
            Area::Rfl ex 01C7BD20 des=(15,15)
          TC::Rfl ex 01C7BDB0 des=(45,45)
        TR::Rfl ex 01C7A330 des=(45,45)
      TRG::Rfl ex 01C7A890 des=(45,45)
    T::Rfl ex 01C7AE60 des=(75,75)
  TO::Rfl ex 01C79060 des=(75,75)

Comment 8

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

Could differences between local and remote have anything to do with the newline
loss described in bug 16584?  This is just a wild guess, but...

Comment 9

[kipp]

The test is consistent now (local/remote) so whatever was causing that has been
fixed. The height of the line issue for standard mode is a dup of 15428 so I'm
marking this bug a dup.


*** This bug has been marked as a duplicate of 15428 ***

Comment 10

[Christine Hoffman]

Verifying dup of #15428

Comment 11

[Masatoshi Kimura [:emk]]

Bug #15428 is fixed, but table cell still have the extra height 
in standard mode.
Reopening.

Comment 12

[Masatoshi Kimura [:emk]]

Attachment: New testcase for standard mode (because HTML 4.01 Transitional no longer trigger the standard mode)

Comment 13

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

I knew there was a bug on this somewhere.  I'm not sure why this isn't fixed,
but I'm going to assign it to myself and I'll look at it tomorrow (hopefully).
I suspect it may show a problem with my fix.  If I can't figure it out I'll send
it back to Kipp's bug list (or maybe to Chris Karnaze, if it looks like a table
problem).

Comment 14

[karnaze (gone)]

Standard and Quirks mode can only be reliably tested in mozilla (not Viewer) 
until I get approval to checkin bug 28071.

Comment 15

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

The problem that this does not work in strict mode is invalid.  It is fixed in
quirks mode.  I am resolving the bug as INVALID, but it should still be verified
as FIXED in the other cases.

Note that, right now (in my release build from yesterday), HTML 4.0 strict is
triggering quirks mode, for some bizarre reason.  However, I can still test
quirks/strict in my (older) debug build.

The testcase given for strict mode should not produce a one-pixel high table
cell.  The combinations of styles that should do so are either:
1) img { display: block; }   /* preferred */
or
2) td { line-height: 0; } img { vertical-align: bottom; /* or top */ }
Both of these work correctly.

The reason that 'td { line-height: 0; }' is not sufficient is that the td's
line-box (assuming our method of anonymous inline boxes is what the spec
intended) has an anonymous inline box that has zero height, but is *above* the
baseline, whereas the img box is on the baseline, and the line-box must include
both.

Comment 16

[Masatoshi Kimura [:emk]]

>The reason that 'td { line-height: 0; }' is not sufficient is that the td's
>line-box (assuming our method of anonymous inline boxes is what the spec
>intended) has an anonymous inline box that has zero height, 

Why does the td's line-box have an anonymous inline box? The td have nothing 
but an img.

Comment 17

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

That's the interpretation bit.  I've argued that the statement in CSS2 that a
line-box cannot have a height smaller than the line-height property of its
containing block should be implemented by anonymous inline boxes, because if it
isn't, all sorts of weird things can happen (like uneven interline spacing in
the presence of reduced fonts).

I'm pretty comfortable with this interpretation because nobody (to my knowledge)
has proposed a workable alternative.  I suspect the inline box model will be due
for a good bit of revision in CSS3.

Comment 18

[Christine Hoffman]

Adding 'verifyme' keyword

Comment 19

[Christine Hoffman]

Verified invalid.