Opened 11 years ago
Closed 11 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: |
Description
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 11 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 Changed 11 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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 11 years ago by
(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 11 years ago by
(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 11 years ago by
| Milestone: | 1.3 → 1.4 |
|---|
comment:6 Changed 11 years ago by
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 dojo.place("<html string>");
We can revisit if we want to expand this more for 1.4.
comment:7 Changed 11 years ago by
please attach the patch with the expanded unit tests and fixes you mentioned earlier.
comment:8 Changed 11 years ago by
| Owner: | changed from alex to dante |
|---|---|
| Status: | reopened → new |
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 11 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I seldom find a time when I can't live without dojo.place 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.
(In [16641]) make sure that create() works with actual markup. Fixes #8613. !strict