Opened 10 years ago

Closed 10 years ago

#8613 closed defect (wontfix)

dojo.create() should support dojo._toDom in string case where createElement fails

Reported by: alex Owned by: dante
Priority: high Milestone: 1.4
Component: Core Version: 1.2.3
Keywords: Cc: dante
Blocked By: Blocking:


we should support the form of:

dojo.create("<div>some content!</div>");

Since this blows up in the case where you try to createElement on that string, we can just catch it and _toDom it instead.

Change History (9)

comment:1 Changed 10 years ago by alex

Resolution: fixed
Status: newclosed

(In [16641]) make sure that create() works with actual markup. Fixes #8613. !strict

comment:2 Changed 10 years ago by dante

Resolution: fixed
Status: closedreopened

you just undid every bit of doc reviewing I did last evening to ensure dojo.create() was accurate.

it was intentional to leave _toDom creation out of of dojo.create() (though I am not 100% behind that decision)

if you dojo.create("<a>hi</a> there", { anyattr }) you are setting attr on a doc fragment. this complicates the API tremendously. we've gone back and forth on this one.

comment:3 Changed 10 years ago by dante

(In [16643]) taking attr setting out of create. is redundant. these all technically beat enhancement cutoff, begrudgingly. refs #8613 - unit tests all pass so they either don't exist or didn't regress. also not sure create() accepting complex markup is the right thing, especially with the implemenetation with the try{}. you can createElement("<iframe blah;>") for instance. !strict

comment:4 Changed 10 years ago by James Burke

(In [16645]) Refs #8612 and #8613. Reverts changesets [16641] [16642] [16643]. dojo.create not accepting html strings has been explicitly discussed as not being included in Dojo 1.3 multiple times now. We can talk about it more for 1.4 after we have had time to let the current create bake a bit in the wild. It is easier to add things later than take away later too. Similarly with NodeList?, while I want an end() in general, i want to be sure we think through the use cases for it, and adding more API. and it was done without adequate notice. \!strict

comment:5 Changed 10 years ago by James Burke

Milestone: 1.31.4

comment:6 Changed 10 years ago by James Burke

Just to follow up on this: for 1.3, create is just a macro for createElement/attrs/style. We discussed the difficulty in explaining multiple top level node returns and how that might interact with the event binding attr can do. For 1.3 it seemed best to have our story as:

dojo.create for doing dom creation of nodes and modifying with JS apis. You can get innerHTML via dojo.create("div", { "innerHTML: "..." });

If you want insertAdjacentHTML functionality, use"<html string>");

We can revisit if we want to expand this more for 1.4.

comment:7 Changed 10 years ago by dante

please attach the patch with the expanded unit tests and fixes you mentioned earlier.

comment:8 Changed 10 years ago by alex

Owner: changed from alex to dante
Status: reopenednew

why? so people can have kumbaya moment around what's clearly a sane API? Or bikeshed it to death? You'll forgive me if I decline.

comment:9 Changed 10 years ago by dante

Resolution: wontfix
Status: newclosed

I seldom find a time when I can't live without to handle the adjacentHTML stuff. For the sake of documentation and clarity, I suggest we leave this through to 2.0. plugd's create() and query() can also make markup this way, so if users want that option is it already available.

Note: See TracTickets for help on using tickets.