#9323 closed bug (wontfix)
"width" and "height" can not be set as attributes when creating an <img> with the props argument
Reported by: | patrickwhalen | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | core | Version: | 1.6.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
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; ">]
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">]
Change History (11)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Component: | unfiled → core |
---|---|
Priority: | undecided → low |
Status: | new → open |
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.
comment:3 follow-up: 4 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
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.
comment:4 Changed 12 years ago by
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.
comment:5 follow-up: 6 Changed 12 years ago by
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?
comment:6 Changed 12 years ago by
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.
comment:7 follow-up: 8 Changed 12 years ago by
And this is not sufficient?
$('<img/>').attr({ width: 10, height: 10 });
comment:8 Changed 12 years ago by
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
comment:9 follow-up: 10 Changed 12 years ago by
@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.
comment:10 Changed 12 years ago by
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
comment:11 Changed 12 years ago by
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!
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