Page is displayed with lots of black boxes

VERIFIED DUPLICATE of bug 991

Status

()

Core
Layout
P3
major
VERIFIED DUPLICATE of bug 991
19 years ago
18 years ago

People

(Reporter: Eugenia Loli, Assigned: buster)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [TESTCASE], URL)

Attachments

(2 attachments)

(Reporter)

Description

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

Updated

19 years ago
Assignee: don → troy
Component: Browser-General → Layout

Updated

19 years ago
Summary: M9 and M10 is screwing up this page → Page is displayed with lots of black boxes

Comment 1

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

Updated

19 years ago
Assignee: troy → karnaze

Comment 2

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

19 years ago
Created attachment 2225 [details]
testcase

Updated

19 years ago
Whiteboard: [TESTCASE]

Comment 4

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Assignee: karnaze → kipp
Status: ASSIGNED → NEW

Comment 5

19 years ago
Reassigning to Kipp based on the following comments from Rob Hulswit
(d.r.hulswit@student.utwente.nl).

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

19 years ago
Created attachment 2399 [details]
test case from 10/25 comments

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M19

Comment 7

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

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

19 years ago
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...
Adding Ian, because he'll probably disagree...
QA Contact: leger → py8ieh=bugzilla
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?)
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...
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.
(Reporter)

Comment 15

19 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
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 ***
QA Contact: py8ieh=bugzilla → chrisd
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! :-)

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 18

19 years ago
Verifying remaining issue as dup of #991
You need to log in before you can comment on or make changes to this bug.