Ticket #7264 (closed bug: wontfix)
createDocumentFragment is not a function.
| Reported by: | anonymous | Owned by: | |
|---|---|---|---|
| Priority: | undecided | Milestone: | 1.5 |
| Component: | unfiled | Version: | 1.4.3 |
| Keywords: | Cc: | ||
| Blocking: | Blocked by: |
Description
Two variants of the $() function are getting confused and the older one is getting used when the newer one is wanted.
Code to trigger:
$('<input type="text" />', {
name: 'test'
});
Note that I use that format specifically because of this text in the documentation for that function: "Note that Internet Explorer will not allow you to create an input element and change its type; you must specify the type using '<input type="checkbox" />' for example."
Known work arounds:
$('<input/>', {
name: 'test'
});
However that would still run afoul the IE issue. This is what I ended up using instead:
$('<input type="text" />').attr({
name: 'test'
});
This was tested with the minified version of jQuery 1.4.2 and the development version of 1.4.3 both on Firefox 3.6.3 and Chromium 5.0.375.127 (0).
Change History
comment:2 Changed 3 years ago by SlexAxton
- Keywords documentFragment create html added
- Status changed from new to closed
- Resolution set to wontfix
I think perhaps the docs could be cleared up on this a bit, but it's not something that needs to change in jQuery. The idea is that the docs would let you know that your use-case is invalid in IE. I think programatically it doesn't make sense to try and sniff out. The solution you came up with is the ideal use.
comment:3 Changed 2 years ago by anonymous
No arguments about the wontfix codeside, but could the docs get an update soon please. I had the same misunderstanding (and as an aside, the pre 1.4 behaviour didn't break the same way - it still didn't work properly, but depending on the args, it kind of looks like it does)
comment:5 Changed 2 years ago by addyosmani
- Keywords documentFragment create html needsDocs removed
Updated: http://api.jquery.com/jQuery/
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

jQuery( html, props ) isn't meant to be used in the way you do in your "trigger code".
The api docs for jQuery( html, props ) state
Passing in as html anything other (complex html, not single standalone tag e.g as above with "inline" attributes) while the second parameter (as in this case) isn't a context but a map of attributes will trigger the exception you mentioned.
Doing
$('<input />', { type: 'text', name: 'test' });fails in IE as stated by the docs. So the only valid way to do this is for input / button elements in IE is exactly what you ended up doing.
Check also my comment on this jQuery-UI commit which caused similar issues (the commit not my comment :D ).