851048 - img without src doesn't honor its width and height (because it's display:inline)

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Andy Reichenbach]

Attachment: away_Character.html

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

Steps to reproduce:

This page: http://www.frogmandesignz.com/away_Character.html is not working in Firefox, but works just fine in IE, Chrome and Safari. 


Firefox version 19.0.2 
Shadowbox.js version 3.0.3 

The problem I've found is if you change this part of the code's id tag of id="away_Walkthrough_img" to img src"some_file.png" it works: <a id="away_Walkthrough_shadow"  href="http://frogmandesignz.com/away3d/walkthrough_web/Walkthrough_Apt_Web.html" rel="shadowbox;height=800;width=840"><img id="away_Walkthrough_img"/></a> 

But this won't work for my setup to produce different size images for different browser window sizes, and as this works with the other browsers I'd assume there must be some way to get this right with Firefox?


Actual results:

No image is displayed on the page and subsequently shadowbox does not work either.


Expected results:

An image should be showing and shadowbox should be able to open up the desired page.  Open the page listed in any of the other browsers and you'll see.

Comment 1

[mjh563]

Yes, the problem is that the image has a CSS width and height but no 'src' attribute set (the image you see in the other browsers is actually a background-image). Firefox doesn't display it for some reason, whereas the other browsers do.

A better way to fix it is by setting 'display:inline-block' on the image. For example, running this in the web console makes it appear for me:

document.querySelector("#portLayout img:not([src])").style.display = "inline-block"

Comment 2

[mjh563]

Attachment: testcase

This testcase displays the Firefox logo in Chrome and Opera, but not in Firefox.

Comment 3

[Boris Zbarsky [:bzbarsky]]

For what it's worth, in _quirks_ mode we'd honor the width and height, but in standards mode I believe our behavior is correct.

Comment 4

[Andy Reichenbach]

Thanks mjh563 that was a HUGE help.

Comment 6

[Boris Zbarsky [:bzbarsky]]

We're doing what the HTML spec says here.

Comment 8

[Daniel Holbert [:dholbert]]

For the record, I'll quote the spec text that supports what we're doing here. (since I just had a reason to find it, & it'll be easier for me to find again it in the future if I paste/link it here)

Firstly, the spec says this sort of <img> "represents nothing":
>  --> If the src attribute is not set and either the alt attribute
>      is set to the empty string or the alt attribute is not set at all
>          The element represents nothing.
https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element


And later in the rendering section, it explains what that means for rendering:
>  --> If the element is an img element that represents nothing and
>      the user agent does not expect this to change
>          The user agent is expected to treat the element as an empty
>          inline element.
https://html.spec.whatwg.org/multipage/rendering.html#images-3

So, we treat it as if it were an empty <span>, basically (as the spec requires).

Comment 10

[Astley Chen (inactive)]

cc Mike Tylor

From bug 1321985 comment 6. I suggest to reopen the bug for tracking this webcompat issue.

Comment 11

[Mike Taylor [:miketaylr]]

img without src reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1302842#c15 as well.

Comment 12

[Karl Dubost💡 :karlcow]

Adding https://webcompat.com/issues/4067 exhibiting this issue.

Comment 14

[Karl Dubost💡 :karlcow]

Thanks Daniel.
https://webcompat.com/issues/16223

Comment 15

[Boris Zbarsky [:bzbarsky]]

It's not clear to me why this is got reopened at all.  If you think the spec should change, please file spec issues.  If you think Chrome should fix its bug, poke them to fix its bug.

Comment 16

[Mark Straver]

https://bugs.chromium.org/p/chromium/issues/detail?id=671871#c11 makes a good point about the spec, and it seems Firefox is not adhering to the spec for the rule that applies:

- <img> without src attribute represents "nothing" (see comment 8), and therefore doesn't represent an image
- If set with CSS rules, the element has intrinsic dimensions already
- The img has no "alt" attribute

The spec says it should be treated as a replaced element in that case.

So, it seems to me that the current quirks mode behavior should be used for standards mode as well.

I gather this bug should be re-opened in light of the above; if you think not, then please enlighten me as to which rules should apply and why :)

(The only question that remains then: what if there *is* an alt attribute and the src is set later -- does it change from an inline element to a block element then? Is that something the spec should clarify?)

Comment 17

[Boris Zbarsky [:bzbarsky]]

CSS rules _outside_ the element don't set intrinsic dimensions.  The only case in which CSS rules produce intrincic dimensions is CSS rules inside and SVG image styling its root element.

See the rest of the conversation in the chromium issue and https://github.com/whatwg/html/issues/3614

Comment 18

[Mark Straver]

Of course. My bad. I'm sorry. You are absolutely correct.

Comment 19

[Karl Dubost💡 :karlcow]

geez…