IE9 adds width and height attribute to new Element('img')

[woomla]

Hi,

When creating a new Element('img') in IE 9, the browser (sometimes)
add width and height attributes to the tag.

If you inspect the Mootools images in http://jsfiddle.net/woomla/6py5D/
you see that in IE9 they have a width of 180 and a height of 60.

Is this a bug in IE? Can mootools do anything about it?

W.

[woomla]

Well it's only now and then. Maybe a bug in my ie9?

On Nov 18, 3:58 pm, woomla <woo...@gmail.com> wrote:
> Hi,
>
> When creating a new Element('img') in IE 9, the browser (sometimes)
> add width and height attributes to the tag.
>

> If you inspect the Mootools images inhttp://jsfiddle.net/woomla/6py5D/

[Olmo Maldonado]

Hrm.. I'm confused what'd be the problem if IE9 (or other browsers) adds attributes to the tag?

[Sanford Whiteman]

> Hrm.. I'm confused what'd be the problem if IE9 (or other browsers) adds
> attributes to the tag?

Changes the display size from auto (file dimensions) to a fixed size,
n'eh? Not that we are supposed to be use using auto....

-- S.

[Olmo Maldonado]

Sure, but those images are 180 x 60. :D 

I'm also having trouble reproducing the width height attribute problem in IE9 with your fiddle.

[Sanford Whiteman]

> Sure, but those images *are** 180 x 60*. :D

Point taken. The prob is that the attributes stick when you change
`src` programatically, then.

> I'm also having trouble reproducing the width height attribute problem in
> IE9 with your fiddle.

Haven't tested the Fiddle yet myself, maybe I should shut up for now.

-- S.,

[Olmo Maldonado]

On Fri, Nov 18, 2011 at 11:52 AM, Sanford Whiteman <sa...@figureone.com> wrote:

> Sure, but those images *are** 180 x 60*. :D

Point  taken.  The  prob  is that the attributes stick when you change
`src` programatically, then.

Possibly, we'd have to play with it. Since I haven't reproduced, though, it'll be hard to spec against the first case and also the case that the source changes.

[Sanford Whiteman]

> Possibly, we'd have to play with it. Since I haven't reproduced, though,
> it'll be hard to spec against the first case and also the case that the
> source changes.

I can repro it every time in IE 9.0.8112.16421 x64, but not in the IE
9.0.8112.16421 Win32 nor in v9.02 Win32. So 64-bit thing?

Create the el with a given src, set the src to something smaller,
inject it, keeps the dims of the original src. I haven't looked at it
much more than that.

-- S.

[Olmo Maldonado]

Yeah I'm 32 bit as well. 

Try this: http://jsfiddle.net/7mKrs/

Looks like IE8, 9 and probably earlier versions have the same behavior. All other browsers correctly resize to the new image size. 

[Sanford Whiteman]

> Looks like IE8, 9 and probably earlier versions have the same behavior. All
> other browsers correctly resize to the new image size.

It's apparently linked to the caching of the original src in some way
(IE has other `src` caching bugs like this). Looks like if you have a
query string, regardless of the actual HTTP-level cacheability, the
problem does not occur. Otherwise it is sporadic (based on some other
heuristic). Play with path?dummy and you should see a diff:
http://jsfiddle.net/sanford/mS6KR/.

-- S.

[Olmo Maldonado]

Here's the fix: http://jsfiddle.net/7mKrs/2/

[Sanford Whiteman]

> Here's the fix: http://jsfiddle.net/7mKrs/2/

Makes sense to me as the brute-force way -- but do you not think it's
something that could go in core as a behavior standardization/fix?

Not that I care about this myself, mind you...

-- S.

[Olmo Maldonado]

Perhaps on Element.set('src')

Although, I'm not sure if there's a practical feature detection, so it'll have to be a flag against the browser. 

[gonchuki]

The actual fix should be removing the width and height attributes, not
setting a CSS style to stomp them over.

I solved this same issue a couple days ago, where we have an "image
viewer" that lazily loads the image via AJAX and then the image is
constrained to the width of the viewport via CSS (max-width: 100%). In
IE9 the image got distorted aspect ratio (height remained the
original), and on IE8 it had the width of the padding box of the
parent. Removed width and height attributes in the load event, and
then everything worked even back to IE7.

[Olmo Maldonado]

I can confirm that removing the property does fix the sizing issue.

http://jsfiddle.net/7mKrs/4/

I've made the overload setter to fix this: http://jsfiddle.net/7mKrs/5/

I'll write a Github Issue in Core. (here it is: https://github.com/mootools/mootools-core/issues/2129).

Thanks for the report.

[Sanford Whiteman]

gonchuki, do you concur with the query string behavior as I pointed to in my Fiddle? Although understandably more annoying than overloading the accessor upfront, I'm curious about whether it really works as I think.

-- S.

[gonchuki]

The strange thing is that our images all have a query string as they
are OAuth signed to go against our storage service. In our case I was
doing the old school hand rolled "var img = new Image(); img.onload =
callback; img.src = 'blah blah';" inserting on the DOM once the image
was loaded.
Anyways, this consistently yielded images with the width and height
attributes hardcoded by IE8 and 9 (strangely, not IE7). Maybe this bug
behaves differently depending on the <img> tag creation method.
(Asset.image uses "new Image()" like my hand rolled solution, new
Element('img') uses document.createElement AFAIK)

[Sanford Whiteman]

> Anyways, this consistently yielded images with the width and height
> attributes hardcoded by IE8 and 9 (strangely, not IE7). Maybe this bug
> behaves differently depending on the <img> tag creation method.
> (Asset.image uses "new Image()" like my hand rolled solution, new
> Element('img') uses document.createElement AFAIK)

Interesting, yeah, maybe that's the difference; in my testbed (2
Win7/IE9 boxes) the query string, any query string, fixes it.

-- S.