height of IMG tag without src attribute set is 0 in Chrome, vs. line-height in Firefox

RESOLVED INACTIVE

Status

()

Core
Layout: Images
RESOLVED INACTIVE
3 years ago
3 days ago

People

(Reporter: hallvors, Unassigned)

Tracking

29 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8650373 [details]
imgnosourceheight.htm

If there's markup like <img> or <img width="200"> and you read element.height, what should it return?

Chrome says 0, and we've found a site depending on this behaviour - see 
https://github.com/webcompat/web-bugs/issues/463#issuecomment-132560088

It seems Firefox currently gives the line-height of the context or something like that.
In quirks mode the img gets a height of zero. The code responsible is http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsLineLayout.cpp?rev=28673cc5e68b#1796
I think this is because we fall back to rendering like a <span>, to display whatever alt-text happens to be provided. (in this case, the empty string)

i.e. we render these URIs the same:
  data:text/html,<img style="border:1px solid black">
  data:text/html,<span style="border:1px solid black"></span>
...whereas Chrome does not (they agree with us on the <span>; they disagree on the <img>).
IMO, our behavior here makes sense according to CSS2 rules for sizing inline elements.

The CSS2 section on calculating heights distinguishes between "Inline, non-replaced elements" (e.g. a span) and "Inline, replaced elements" (e.g. a video, or an image that has image data to render):
 https://drafts.csswg.org/css2/visudet.html#inline-non-replaced
And an <img> with no image data (no src attribute) is *non-replaced*, in the sense that it's not being filled in with image data. So, it's sized like a *non-replaced* element, i.e. like a <span>.

So, I think our behavior makes sense, according to the spec.

(I'm not sure what Chrome's doing, but I suspect they're (1) considering the element to be replaced, and (2) considering the element to *have* an intrinsic height, of 0. Given those assumptions, I think their behavior makes sense.)
Summary: height of IMG tag without src attribute set should be 0 → height of IMG tag without src attribute set is 0 in Chrome, vs. line-height in Firefox
For comparison, using <img style="border:1px solid black"> in standards-mode:
 - MS Edge matches Chrome -- it renders just a small dot, and renders a 0-height wide element if I add a 'width' attr.
 - IE 11 does its own thing -- it renders a 30x30 square, and renders a taller square if I add a 'width' attr.
 - Opera 12 (Presto) does yet another different thing -- it renders an approximately-line-height thing that just says the word "Image".

If we disregard IE11 and Opera 12 as deprecated, then that leaves us as the odd one out, in terms of our rendering behavior for <img> without a src attribute, among modern browsers.  So, even though our behavior is defensible from a spec perspective (comment 3), it might be worth considering a switch.
(Note: I didn't test any webkit-based browsers; I'm assuming they behave approximately like Chrome, too.)
Gecko's behavior of treating image elements without data loaded as much more like regular inlines might not be something all browsers do -- and it might be something that now gets us into Web compatibility trouble.
Making img's always create an nsImageFrame (instead of an inline frame before we have decoded the size of the image and then an image frame) would simplify the code too.
True.  It would also make alt text not really usable unless the alt text is extremely short and fits in the image box.  :(  Note that the HTML spec does cover this situation and we follow the spec; Chrome unfortunately does not.

Now what we could do is not fall back to the inline frame case if there is no alt text provided at all.  That might be a sensible thing to do, and may be compliant with the HTML spec; I haven't checked what the exact verbiage there is recently.

Comment 9

3 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 3 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.