Open
Bug 333954
Opened 19 years ago
Updated 2 years ago
Broken image icon doesn't show in strict mode
Categories
(Core :: Layout, defect)
Tracking
()
NEW
People
(Reporter: pile0nades, Unassigned)
References
()
Details
(Whiteboard: DUPEME)
Attachments
(1 file)
309 bytes,
text/html
|
Details |
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.
Reporter | ||
Comment 1•19 years ago
|
||
Just removing the url from the doctype fixes the bug.
Reporter | ||
Updated•19 years ago
|
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
Updated•19 years ago
|
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
Comment 2•19 years ago
|
||
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
Updated•19 years ago
|
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
Updated•19 years ago
|
QA Contact: general → layout
Comment 3•16 years ago
|
||
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.
Comment 4•16 years ago
|
||
(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 ?
Comment 5•16 years ago
|
||
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.
Comment 6•14 years ago
|
||
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.
Comment 8•14 years ago
|
||
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;
}
Comment 9•13 years ago
|
||
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
Comment 10•13 years ago
|
||
Filed bug 672465 for "-moz-force-broken-image-icon: 1;" no longer working.
Comment 11•13 years ago
|
||
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
Comment 12•13 years ago
|
||
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?
Comment 13•13 years ago
|
||
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.
Comment 14•13 years ago
|
||
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"?
Comment 15•13 years ago
|
||
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.
Comment 16•13 years ago
|
||
From that spec it looks like anything with EITHER a height or width of zero should be treated as not having an intrinsic ratio?
Comment 17•13 years ago
|
||
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....
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•