"width" and "height" can not be set as attributes when creating an <img> with the props argument

[patrickwhalen]

It isn't possible to add "width" and "height" attributes via the "props" object argument when creating a new <img>.

Code example taken from this StackOverflow question: ​http://stackoverflow.com/questions/6037231/bug-in-jquery-dom-element-builder-for-images-with-width-height

var x = $('<img/>', {width:10, height:20});

x; // => [<img style=​"width:​ 10px;​ height:​ 20px;​ ">​]

​http://jsfiddle.net/gY97g/

This is because jQuery calls its own width and height methods, which conflict with the legitimate width and height attribute.

I'd imagine it is too late to remove the conflict, so a possible workaround would be to add the attr method as one that jQuery will invoke from the "props" argument.

$('<img/>', {attr:{width:10, height:20}});

x; // => [<img width="10" height="20">​]

[patrickwhalen]

Verification that the attributes are active, and not deprecated.

HTML 4.0.1 ​http://www.w3.org/TR/html401/struct/objects.html#h-13.2

XHTML 1.1 ​http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Image

HTML 5 ​http://www.w3.org/TR/html5/embedded-content-1.html#the-img-element

[timmywil]

I see the point, but this would only apply for certain tags and I'm not sure we want to make that distinction in core. Since you can use attr to explicitly set the attributes, I don't think this convenience option should get any extra code.

[dmethvin]

I agree it's an ambiguity, but like you say there's no way to fix it now. I don't think it's worth adding more complexity to support this when the API makes it easy to add .attr() to the end of the chain to set width and height.

[patrickwhalen]

Replying to dmethvin:

...I don't think it's worth adding more complexity to support this...

I would suggest that adding a potential attr call to the props argument should be seen as a logical addition to the API akin to the css call, rather than a mere fix for these two properties.

It may seem to be a slightly odd bit of redundancy, but I don't think it would be in the way, and may in fact make more sense to users than having jQuery methods mixed in with a set of attributes.

Barring your agreement, then I'd at least suggest you consider it to be a documentation bug. Let people know that they may set valid or custom attributes except for valid or custom attributes that conflict with the designated set of jQuery methods that can be called alongside setting those attributes because the methods have a higher priority.

[Rick Waldron]

I'd like to shift the conversation towards a purely academic context; What is the real reason you'd like to use width/height attributes to control the presentational style of your image? The first appearance of the width/height attributes being applied to IMG elements was in January of 1997 with release of HTML3.2 (​http://www.w3.org/TR/REC-html32.html#img ). One month prior, to this appearance of width/height on IMG elements, the CSS1 ( ​http://www.w3.org/TR/CSS1/ ) spec recommendation was published, which included width/height styles for IMG elements.

I'm sure you can imagine how that went down,

"Why are we defining presentational information as part of the element own specification???"

..silence...

"I know! We'll create an abstract styling specification! It will allow width/height [among other] to be set for EVERYTHING... without requiring HTML parsers to add more to their tokenization tables!"

In a nutshell, before it was even official, it was already being replaced. So enlighten me, why would you prefer to apply presentational information to IMG elements using width/height attributes instead of CSS?

[patrickwhalen]

Replying to rwaldron:

...before it was even official, it was already being replaced. So enlighten me, why would you prefer to apply presentational information to IMG elements using width/height attributes instead of CSS?

Why would I prefer? This isn't about me. I was on StackOverflow taking part in helping a user of your library understand why a feature didn't work as expected. His issue was legitimate. There is a conflict. Those attributes have not been replaced as you suggested. They are still very much part of the spec, likely because they are legitimate attributes of an image.

I assume the conflict was an oversight. It can't be resolved at this point, but it seemed that it would be possible to maintain the benefit of that feature of your library by adding an attr option. Because of this, I filed a report, which at the very least serves as a record of the issue.

You can take it from there.

[Rick Waldron]

And this is not sufficient?

$('<img/>').attr({
    width: 10,  
    height: 10
});

[anonymous]

Replying to rwaldron:

And this is not sufficient?

$('<img/>').attr({
    width: 10,  
    height: 10
});

I've closed my account because your behavior was condescending. Now you're just being obtuse.

Please read these points very carefully.

• I was helping someone with your library.
• There is a legitimate conflict in spite of your baffling attempts to avoid acknowledgement of it.
• I took the time to report the conflict.
• You take it from there. If that means you do nothing, that's absolutely fine with me.

patrickwhalen

[john]

@patrick: I suspect that .prop({ width: 10, height: 10 }) (in jQuery 1.6+) will meet the needs of the user that you're trying to help.

[patrickwhalen]

Replying to john:

@patrick: I suspect that .prop({ width: 10, height: 10 }) (in jQuery 1.6+) will meet the needs of the user that you're trying to help.

@john: Hi. Thanks for your input. Yes, the new .prop() method would work as well. The .attr() method of course works too, as would setting the attributes or properties without jQuery.

The main point of the report was the inability to set those two attributes directly when passing a map of attributes as a second argument while creating a new element in jQuery.

As in:

 
var img = $( "<img/>", {src:"some/path/to.jpg", width:120, height:90} );
 

This fails to set the attributes, but rather sets the inline style properties, because the attributes are shadowed by the jQuery's width and height methods which have a higher priority.

It presents an ambiguity that is too late to reverse, so I was proposing an alternative that would at least provide a resolution within the context of this feature of jQuery.

They decided against its implementation, and that's fine. I was just getting miffed at that rwaldron guy because he was trying to get me into a position of defending a practice, when I was merely pointing out a legitimate issue in the API that had apparently been overlooked.

Anyway, I do appreciate that you took the time to offer an alternative. :o)

Best regards,

patrick

[Rick Waldron]

Patrick, I feel bad that my comments above were misunderstood (tone wise) - I was trying to lighten the mood. Anyway, sorry for any misunderstandings

As always: Be Excellent to eachother!