16046 - Page is displayed with lots of black boxes

Status: VERIFIED DUPLICATE of bug 991

(Core :: Layout, defect, P3)

Description

[Eugenia Loli]

M9 and M10 is screwing up this page @ http://www.ukbug.org.
Just browse there and you will see it Mozilla to render it very badly.
Opera3+, IE3-4-5 and Netscape 4+ are rendering the page correctly.

Thanks,
Eugenia.

Comment 1

[troy]

Changed URL to framecell URL rather than top-level frameset URL. Also changed
the summary to be more informative

Comment 2

[troy]

Very heavy use of tables so reassigning to Chris. Someone (hopefully not Chris)
needs to try and narrow the problem down a bit

Comment 3

[Mats Palmgren (inactive)]

Attachment: testcase

Comment 4

[Mats Palmgren (inactive)]

I see some minor glitches in Navigator 4.08 too. IE5 renders it perfect. (Win98)

Comment 5

[karnaze (gone)]

Reassigning to Kipp based on the following comments from Rob Hulswit
([e-mail]).

The main cause of the black boxes that occur in the test-case is the image
"image/blank.gif". That image does not exist and Mozilla therefore shows the
text "blank". Because the background in the cell is black (just like the text),
the cell will be totally black, creating a black box.

The most important issue here is thus: When an image does not exist, and it's
width/height are defined, the alt-text does not have the dimensions specified
for the image. This messes up the layout of the page.

I have modified the background in the testcase, and sent it as an attachment
with this mail. It shows very clearly what's the issue here.

Comment 6

[karnaze (gone)]

Attachment: test case from 10/25 comments

Comment 7

[kipp]

In order to fix this we need to either (a) stop doing what the html spec says
with regard to alternate content for unloadable images or (b) implement
"inline-block" ala css3 and make the inline frames we create with the alternate
content be of that display type...

Comment 8

[kipp]

Here are troy's thought's on the matter:

My opinion is that we mark the bug INVALID. I'll be happy to do that. It's
not the first of this type of bug I've marked INVALID.

It's a well known issue that width/height to not apply to non-replaced
inline elements (which is what the image's alternate text is).

They really shouldn't be doing stuff like that

Ian has a bug assigned to me (I probably LATER'D it, but it wouldn't be all
that hard to implement) that states that we should provide a pseudo class
style (something like :broken) that can be used to specify the style that
applies to the alternate content. For example:

IMG:broken {
  display: block;
}

That would be helpful to people.

Inline-block might be useful as well, but I don't know how we would
automatically know what to do. The IMG itself was inline-level, and so the
alternate content is as well.

If they had made the IM block-level, then the alternate content would have
been as well

Comment 9

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

One could also argue that the alt text of an IMG is replaced content (as opposed
to that of an OBJECT, which clearly isn't)...

Comment 10

[kipp]

I guess I could agree that it's logically a "replaced" element at that
time...I'll see what can be done on the cheap...

Comment 11

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

Adding Ian, because he'll probably disagree...

Comment 12

[Hixie (not reading bugmail)]

Thanks David -- I agree entirely with Troy on this issue. Our current behaviour
is fine. The page is broken -- have you seen it in Lynx? -- they should (a)
specify alt text for every image, and (b) actually have the image available.
I think it is about time we gave authors who write pages like this a bit of
a wakeup call.

leger: I'm taking over QAC as this is an alt text bug.

kipp: If you _do_ find some sort of fix, please make sure its only a quirks
mode thing. The standard mode behaviour is perfect. (Modulo bug 1994 and its
friends, anyway.)

BTW, one fix which would work quite well here and would not AFAICT break any
pages and would be spec compliant to boot is:

   td > img { display: block; }

It might be worth a try. (David: Do you see any problems with that?)

Comment 13

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

Yes.  Major problems:

<td>
  Solving the equation <img src="eqn24.png" alt=" x^2 / ( x^3 + 1) = 72">
  yields...
</td>

(And yes, that image also matches td > img:first-child:last-child .)

Ian's probably right, but it'll probably annoy some people...

Comment 14

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

Reporter responded by email:
---
I included the blank.gif and now Mozilla renders it perfectly.
Don't flame me about my "HTML skills" because this is not my code, and this
pages has been made with GoLive! for Mac.
Also, my next consideration on this page(http://www.ukbug.org) is that the
style sheets are not diplaying correctly. I am talking about the menus on
the left. Check them on IE4+ and then on Mozilla and you will see that
Mozilla is not using the CSS correctly.
Any thoughts on that?
---

What *exactly* is wrong with the menus?  I don't see a problem comparing them
with Nav 4.61.  IE5 isn't available on Linux.

Please respond on the bug, not by email.

Comment 15

[Eugenia Loli]

Well, my CSS I include there are pretty basic and I expect Mozilla to work well.
Netscape 4.60 is rendering the text on the left hand side nicely, with Verdana
in 9px size. My M9 is rendering it with Courier in font size 2.

Comment 16

[Hixie (not reading bugmail)]

David: oops, right. What about
   td > img:first-node:last-node { display: block; }
...except that currently only :first-node is supported. (I intend to propose
both of these to www-style sometime this century.)

eloli: I could not find any CSS that specified font-family on the page. Could
you tell me exactly where it is? It appears to me that it is trying to set the
font by nesting a <table> inside a <font>, which is invalid. Mozilla is
(correctly) ignoring it. Internet Explorer and Netscape 4 were *way* too lenient
in their interpretation of the specs. Try passing the page through a validator:
   http://www.htmlhelp.com/tools/validator/
   http://validator.w3.org/
...to see other errors it has.

kipp: the only remaining issue on this page is therefore a dup of bug 991.
Marking as such.


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

Comment 17

[Hixie (not reading bugmail)]

chris: I'm QA assigning to you since I marked it DUP and noone else has
verified it -- so if you agree it is a DUP then feel free to verify it! :-)

Comment 18

[Christine Hoffman]

Verifying remaining issue as dup of #991