New issue
Advanced search Search tips

Issue 671871 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Handling of <img> tags with no src attribute doesn't follow the HTML spec

Reported by bzbar...@mit.edu, Dec 7 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:53.0) Gecko/20100101 Firefox/53.0

Example URL:

Steps to reproduce the problem:
1. Load the attached testcase.

What is the expected behavior?
No red.

What went wrong?
There is red.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 56.0.2924.18 (Official Build) dev (64-bit)  Channel: n/a
OS Version: OS X 10.10
Flash Version: 

See https://bugzilla.mozilla.org/show_bug.cgi?id=851048#c8 for the spec references.
 
baz.html
119 bytes View Download
Cc: rbasuvula@chromium.org
Labels: M-57 OS-Linux OS-Windows
Status: Untriaged (was: Unconfirmed)
Tested the issue on chrome Stable #55.0.2883.75, Canary 57.0.2943.0 & Dev #56.0.2924.18 in Mac 10.11.6 and was able to reproduce the issue.

This is a Non-Regression issue since seeing this from M30 #30.0.1549.0, Making the status to Untriaged so that the issue would get addressed.

Note : Able to reproduce the issue in windows 10.0 and Linux Ubuntu 14.04.

Thank you.
Tested the issue on Chrome 54.0.2840.85 on Android 4.4.2 and was able to reproduce there, also.
Components: -Blink Blink>Image
Owner: schenney@chromium.org
Status: Assigned (was: Untriaged)
Relevant comment from bugzilla:
----------------------
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).
------------------
Note that the spec text seems to imply that a will-change of some kind might change the behavior.
Labels: -OS-Linux -OS-Windows -OS-Mac -M-57 OS-All
> a will-change of some kind might change the behavior.

I think this only applies if an image isn't yet available, but expected to become available (e.g. when a network request completes).
If an <img> is simply otherwise empty (e.g. source URL to be filled by js DOM changes later) there's no way for a browser to, as the spec says, "expect this to change" at parse/layout time.

Comment 8 by kdub...@mozilla.com, Mar 29 2018

Cc: foolip@chromium.org rbyers@chromium.org
Labels: Hotlist-Interop
This creates webcompat issues for Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=851048

Some developers are using img without src and expect it to work.
https://webcompat.com/issues/4067
https://webcompat.com/issues/16223

Comment 9 by kdub...@mozilla.com, Mar 29 2018

Added a test case
https://codepen.io/webcompat/pen/vRdWoN
Thanks for the update. Still not sure when I'll get to it.

Comment 11 by f...@opera.com, Apr 6 2018

We apply the second rule from the list at https://html.spec.whatwg.org/multipage/rendering.html#images-3 (the rule quoted above is the fourth rule, and hence not the "first applicable"):

> If the element does not represent an image, but the element already has intrinsic dimensions (e.g. from the dimension attributes or CSS rules), and either:
>     the user agent has reason to believe that the image will become available and be rendered in due course, or
>     the element has no alt attribute, or
>     the Document is in quirks mode
>         The user agent is expected to treat the element as a replaced element whose content is the text that the element represents, ...

(with the relevant keys being "does not represent an image" ["nothing" != "image"], "has intrinsic dimensions" and "has no alt attribute")

Comment 12 by bzbar...@mit.edu, Apr 6 2018

But in this case there are no intrinsic dimensions.  The "CSS Rules" clause of the "intrinsic dimensions" bits means things like rules inside an SVG image.  In particular, https://drafts.csswg.org/css2/conform.html#intrinsic (which is what "intrinsic dimensions" links to) clearly says:

> The width and height as defined by the element itself, not imposed by the surroundings

and the CSS rules in the document the image is embedded in are definitely surroundings.

Comment 13 by bzbar...@mit.edu, Apr 6 2018

Put another way, that clause is meant to handle:

  <img width="100" height="100">

with no src and no alt.  Which is not the case we're looking at here.

Comment 14 by f...@opera.com, Apr 6 2018

I guess the "CSS Rules" bit would only ever come into play when the "...has reason to believe..." condition is true then? Otherwise there wouldn't be intrinsic dimensions to take into consideration except the ones from the dimension attributes.
Anyway, this makes it fairly easy to see where the bug is in the implementation =).

Comment 15 by bzbar...@mit.edu, Apr 6 2018

Oh, good point.  This spec is somewhat misusing the concept of "intrinsic dimensions" to start with; I filed https://github.com/whatwg/html/issues/3614 on that.  Basically, I don't see any way you can get intrinsic dimensions here unless you are representing an image; the spec should just clearly say it's talking about the dimension attributes.

Comment 16 by f...@opera.com, Apr 6 2018

Thanks for filing the issue, the "not representing an image" bit was indeed what made me (and possibly whoever implemented the current behavior) think something else was intended here.
Cc: emilio@chromium.org

Sign in to add a comment