dojo.html.set() won't add <option> tag to <select> tag in IE7

[Scott]

See attached code.

Expected that IE7 will create a the following code: <select><option>one</option><option>two</option></select>

Actual results: it appears to create the <select></select> but no <option>s are available.

Succeeded on Mac/FF3 and Mac/Safari3, failed on IE7.0.6000.16764/Vista against dojo 1.3.0b1.

[Scott]

test case

[Eugene Lazutkin]

I was hoping to avoid touching this function at all, and remove it completely in the next version. Its API is complicated and doesn't fit neatly in the new paradigm (dojo._toDom()).

In this particular case dojo.html.set() calls can be replaced with:

//dojo.html.set( dojo.byId('testdiv'), '<select id="testselect"></select>' );
dojo.place('<select id="testselect"></select>', "testdiv", "only");
//dojo.html.set( dojo.byId('testselect'), '<option>one</option><option>two</option>' );
dojo.place('<option>one</option><option>two</option>', "testselect", "only");

I am deferring this ticket to James suggesting to close it as "wontfix", and to mark dojo.html.set() as "deprecated".

[James Burke]

(In [16961]) Refs #8730, mention dojo.place as a viable alternative to dojo.html.set.

[James Burke]

Noted in the docs for this method (both in API docs and on docs.dojocampus.org) that dojo.place() may be a better choice for straight HTML insertion. Moving this to 1.4 milestone to see if we can convert it to use dojo._toDom() underneath to make the HTML insertion capabilities more robust.

I do not think it is critical to do for 1.3, since this affects ContentPane?, and in all likelyhood, use of dojo.html.set() via ContentPane? will not run into the HTML gotchas that dojo._toDom() handles, since it is more likely to insert larger, more complete blocks of HTML.

[James Burke]

Fixed with latest dojo.html changes.