Bug 43559 – Computed style of an image being loaded has height and width 0px instead of auto (Products don't show on plan-itinteriors.com)

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[harry]

See summary - that's all there is to it!

I don't know what version this is - but Safari 5 and Chrome 5 are both having issues (tried lots of different versions too)

[Alexey Proskuryakov]

I cannot reproduce this. Here is what I did:
1. Opened http://www.plan-itinteriors.co.uk/
2. Hovered "Products" in site menu bar - a huge submenu appeared.
3. Clicked the first option, "Consul Manager Executive Range".

It seemed that everything loaded correctly.

[harry]

Hi Alexey,

Thanks for your reply.

You should notice on the home page that there are no products (just a few dots)

On other browsers, you'll see the whole product list.

If you then go to another page, and then back again, you'll see that the products appear.

Thanks

[Alexey Proskuryakov]

Thanks for the clarification, I see it now.

[harry]

OK - any ideas? Is there something we can change in the source code?

[Alexey Proskuryakov]

Created attachment 63716 [details]
screenshot

[harry]

that's it!

[harry]

Hi Alexey,

Just wanted to see if there was any updates with regards to this.

Thanks,
Harry

[Alexey Proskuryakov]

Created attachment 65177 [details]
reduced test case

[Alexey Proskuryakov]

The issue here is that a script manipulates the images' width/height before they have finished loading. Firefox returns "auto" in this case, while WebKit returns "0px" - and setting the dimensions back to that makes the image remain 0x0 pixels forever.

This code in captions.js should be made ready for 0px width and height:

			var w = _img.css('width');
			var h = _img.css('height');
			$('.caption',$this).css({'color':o.caption_color,'background-color':o.caption_bgcolor,'bottom':'0px','width':w});
			$('.overlay',$this).css('background-color',o.overlay_bgcolor);
			$this.css({'width':w , 'height':h, 'border':o.border});

Alternatively, the code can be executed when document is loaded, not just ready (in jQuery, the latter means that the document itself has finished loading, but not necessarily its subresources).

[Alexey Proskuryakov]

Something like this should probably do the trick:

			$('.caption',$this).css({'color':o.caption_color,'background-color':o.caption_bgcolor,'bottom':'0px','width':'auto'});
			$('.overlay',$this).css('background-color',o.overlay_bgcolor);
			$this.css({'border':o.border});

[Alexey Proskuryakov]

Chromium folks WONTFIXed the same issue before, see <http://code.google.com/p/chromium/issues/detail?id=20180>.

Per the Chromium bug report, IE behaves the same as Safari, which makes me wonder why/if it doesn't have the same issue on this site.

[Alexey Proskuryakov]

Maybe it's because IE doesn't have getComputedStyle, so jQuery emulates it with currentStyle, which probably has a different behavior. This begins to sound like a jQuery bug.

[Ojan Vafai]

A Firefox nightly returns pixel values from getComputedStyle. The difference appears to be tied to the timing of the load event.

If you listen to window's load event instead of DOMContentLoaded, then Firefox and WebKit get the same results. It appears the Firefox renders the image before DOMContentLoaded fires. Also, in Firefox, if the image is cached, then you get the full-size image. If it's not, then you get a 24px/24px image. Opera always gets the full-size image.

Not sure what the correct fix is here, but WebKit does seem to be the odd one out.

[Alexey Proskuryakov]

Yes, I was sometimes getting "auto" in Firefox, and "24px" other times. Not sure what exactly I was doing differently, but 24px was more common on the reduction.

[Ojan Vafai]

(In reply to comment #14)
> Yes, I was sometimes getting "auto" in Firefox, and "24px" other times. Not sure what exactly I was doing differently, but 24px was more common on the reduction.

Interesting, with the test case in question, I can't seem to get auto out of Firefox 3.6 or 4. I get 24px if I shift+reload and 215px by 174px on a regular reload (i.e. when the image is cached).

I did find a page that consistently returns auto in Firefox 3.6 and 4 if you shift+reload. http://tinyurl.com/24qmgck

It's not clear to me what the correct behavior is.

[Ojan Vafai]

Discussion on #whatwg:
[12:27pm] ojan: annevk5: are there any cases where returning "auto" from getComputedStyle is correct?
[12:27pm] annevk5: yeah
[12:27pm] annevk5: ojan, e.g. for 'top'
[12:28pm] annevk5: iirc
[12:28pm] ojan: annevk5: i'm looking at https://bugs.webkit.org/show_bug.cgi?id=43559. there's a case where WebKit returns 0px and Gecko returns auto
[12:28pm] dbaron: also for other things that are display:none or inside something display:none, I think
[12:29pm] annevk5: ojan, the reason for that is because I aligned with WebKit; Gecko returns the used value there
[12:29pm] annevk5: ojan, oh, that's the reverse
[12:29pm] ojan: it's getting the computed width/height on an uncached image
[12:29pm] annevk5: dbaron, yeah, or where the property is in the special list and does not apply to the element
[12:29pm] ojan: shift+reload http://tinyurl.com/24qmgck to see the difference
[12:31pm] annevk5: ojan, I guess that is because in Gecko the image is treated as inline element so 'width' does not apply and therefore returns the computed value rather than the used value
[12:31pm] ojan: oh, interesting.
[12:31pm] annevk5: ojan, pretty sucky that pages can depend on how browsers generate boxes for replaced elements while loading 
[12:32pm] ojan: this sounds like a scary thing to change (for webkit or gecko) 
[12:32pm] annevk5: sounds like an annoying thing to define too
[12:32pm] annevk5: i guess HTML5 should define that
[12:33pm] • annevk5 checks the rendering chapter
[12:35pm] annevk5: http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#images-0 has the WebKit behavior
[12:36pm] annevk5: http://www.w3.org/TR/CSS21/visudet.html#the-height-property "the percentage or 'auto' (see prose under <percentage>) or the absolute length; 'auto' if the property does not apply"
[12:37pm] annevk5: (and it does not apply with the Gecko <img> model; assuming I guessed all this correctly)
[12:39pm] crash\: there is a Bug for that
[12:39pm] crash\: https://bugzilla.mozilla.org/show_bug.cgi?id=321919
[12:39pm] crash\: pretty much the same problem
[12:40pm] annevk5: crash\, with the same conclusions
[12:41pm] crash\: what does getPropertyValue("width") for <input type=hidden> return?
[12:41pm] crash\: should be auto too, right?
[12:42pm] annevk5: yes
[12:44pm] crash\: maybe I should create a bug and test case for that to clarify that
[12:45pm] annevk5: make a test suite for getComputedStyle, that'd be neat 
[12:47pm] crash\: I can't see where the specs say. what behaviour is right
[12:48pm] annevk5: http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle defines it
[12:48pm] annevk5: if anything is unclear please email www-style
[12:52pm] crash\: "If the property applies to the element or pseudo-element and the resolved value of the 'display' property is not none, the resolved value is the used value." for width/height
[12:52pm] crash\: but a not loaded image is not of type display:none;
[12:53pm] annevk5: crash\, no, it's of type inline in Gecko
[12:53pm] crash\: yes, so it should be the computed value
[12:53pm] crash\: so I guess 0px would be right
[12:53pm] annevk5: no, auto
[12:54pm] annevk5: we just discussed this in this channel
[12:54pm] annevk5: I even quoted http://www.w3.org/TR/CSS21/visudet.html#the-height-property
[12:54pm] crash\: ok, since it's inline
[12:55pm] crash\: but when it was replaced it can have a width/height
[12:55pm] crash\: wired
[12:59pm] crash\: ist still dont think "auto" is right 
[12:59pm] crash\: why it can't be 0px and when it can't be replaced and then alt="" is used be "auto"?
[1:00pm] annevk5: crash\, sure, that is what HTML5 defines right now
[1:00pm] annevk5: crash\, but apparently that breaks sites
[1:01pm] annevk5: crash\, again see above for the WebKit bug report
[1:02pm] crash\: ok, that confident me

My read from that is that the spec was written to match WebKit, but that breaks at least this site. Seems like we should change to match Gecko and get the spec changed?

[Brent Fulgham]

Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.

[Alexey Proskuryakov]

The attached test bit rotted, but even when fixed, it behaves the same in all browsers.