Open Bug 333954 Opened 18 years ago Updated 2 years ago

Broken image icon doesn't show in strict mode

Categories

(Core :: Layout, defect)

1.8 Branch
x86
Windows XP
defect

Tracking

()

People

(Reporter: pile0nades, Unassigned)

References

()

Details

(Whiteboard: DUPEME)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060307 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060307 Firefox/1.5

When the DOCTYPE has http://www.w3.org/TR/html4/loose.dtd in it, the broken image icon does not show for broken images. I found this on Fark, which adds a grey border around images; broken images appear as a tiny grey sliver. See testcase.

Reproducible: Always

Steps to Reproduce:
1.Open testcase.
2.see grey border around non-existent image

Actual Results:  
Broken image icon did not appear

Expected Results:  
Broken image icon should have appeared.
Attached file testcase
Just removing the url from the doctype fixes the bug.
Summary: Broken image icon doesn't show when DOCTYPE has http://www.w3.org/TR/html4/loose.dtd specified → Broken image icon doesn't show when DOCTYPE has h**p://www.w3.org/TR/html4/loose.dtd specified
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Product: Firefox → Core
Summary: Broken image icon doesn't show when DOCTYPE has h**p://www.w3.org/TR/html4/loose.dtd specified → Broken image icon doesn't show when DOCTYPE has http://www.w3.org/TR/html4/loose.dtd specified
Version: unspecified → 1.8 Branch
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060413 Firefox/3.0a1 ID:2006041321 [cairo]

confirmed on trunk
Summary: Broken image icon doesn't show when DOCTYPE has http://www.w3.org/TR/html4/loose.dtd specified → Broken image icon doesn't show in strict mode
QA Contact: general → layout
I think this should be wontfixed.

In strict mode, we should only render alt text and not include some unstandardized images. When there is no alt text given (missing alt attribute) we /could/ display an broken image icon as the document doesn't conform to the html standard anyway, but I think our current behavior is OK and matches other browsers.
(In reply to comment #3)
> I think this should be wontfixed.
> 
> In strict mode, we should only render alt text and not include some
> unstandardized images. When there is no alt text given (missing alt attribute)
> we /could/ display an broken image icon as the document doesn't conform to the
> html standard anyway, but I think our current behavior is OK and matches other
> browsers.

Why should Joe User know the difference between loose and strict ?
Changing the behavior of the interface based on a hidden and imperceptible change in the content doesn't seem right.  Joe User doesn't just lack knowledge of the difference, he lacks knowledge of their existence.
Since this has come up in the MozillaZine forums again, perhaps an amicable solution would be to make browser.display.show_image_placeholders a tri-state preference.

0 - no placeholders
1 - placeholders in quirks mode (default)
2 - placeholders in quirks and standards modes

This way the current behavior is maintained while giving users the option to change it.

Regarding the handing of alt text, that's what -moz-force-broken-image-icon is for.
I think this should indeed be made configurable by the show_image_placeholders pref, and while we're at it, let's allow that to turn on force broken image icon too.  I don't wanna recompile my browser to get that on; it's not some fundamental extra functionality that requires extra libraries or something.  If it's a pref I can make it GUI-configurable in my addon.
You don't need to recompile anything to absolutely force the broken image icon.

-moz-force-broken-image-icon is a CSS directive you can place in your userContent.css

https://developer.mozilla.org/en/CSS/-moz-force-broken-image-icon

For example

img:-moz-broken
{
  -moz-force-broken-image-icon: 1;
  height: 25px;
  width: 23px;
}
The -moz-force-broken-image-icon: 1; attribute appears to no longer do anything in Firefox 4.0.1 and Firefox 5.

Discussion at http://stackoverflow.com/questions/303718/firefox-browser-how-to-display-non-existing-images-the-way-ie-opera-does/6744791#6744791
Filed bug 672465 for "-moz-force-broken-image-icon: 1;" no longer working.
This is working as designed at the moment...  Since we can show either the alt text or the icon, we show the alt text.

There are existing bugs on showing both of which this seems to be a duplicate.
Whiteboard: DUPEME
Matthew's code forces broken image placeholders to be 25px x 23px, but I wanted to just set a minimum size and allow the HTML to set a bigger height/width if it wanted, so I tried switching those CSS rules to min-height and min-width.  This works for broken images with ALT text, but weirdly for ones without ALT text (and without height/width set), it only causes the height to be 25px; width remains at 0px.  DOM Inspector gives me the computed style values:
min-width:23px;
width:0px

Why would this be happening?  Is it worthy of (yet) another bug?
I can't reproduce the dependence on "alt" text.  I see the behavior where min-width has an effect in quirks mode, and the behavior where it does not in standards mode.

The reason this happens is that in quirks mode replaced element images which don't actually have a size available get intrinsic dimensions of something like 24px by 24px.  In standards mode, the intrinsic dimensions are 0px by 0px for lack of anything better.

Then the table at http://www.w3.org/TR/CSS21/visudet.html#min-max-widths is consulted.  Unfortunately, this involves a bunch of divide by zero kind of things in this situation, so the behavior is not exactly defined.  Worth filing a bug on the CSS spec for that, perhaps.  That said, I believe we convert the divisions into multiplications on the other side, so we end up in the case where min-width*h <= min-height*w (because both are 0) and then height is set to min-height while width is set to min(max-width, min-height*w/h) and we just treat 0/0 as 0 (because we have to produce _some_ number and this makes as much sense as any).  Again, the spec probably needs to be fixed here to work for cases when w or h or both might be 0.
Ugh, that's terrible.  Is there some way to say "if width and height are over 0, then apply this css rule, otherwise apply that css rule"?
Not really, no.  One could argue that we should treat the 0x0 case as not having an intrinsic ratio, I guess.  _That_ may be worth a bug.
From that spec it looks like anything with EITHER a height or width of zero should be treated as not having an intrinsic ratio?
The spec doesn't really define when things do or do not have an intrinsic ratio.  Note that in some cases (e.g. SVG) you can have an intrinsic ratio without even having a concept of intrinsic width or height....
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: