Re: [DOM4]: Element.create

On 9/20/2011 6:47 PM, Sean Hogan wrote:
> On 21/09/11 11:21 AM, Dominic Cooney wrote:
>> It would be nice, in addition to HTMLElement.create, if elements could
>> be created directly using new and the constructor taking similar
>> arguments, eg
>>
>> HTMLElement.create('div', {...}, ...)
>>
>> is the same as
>>
>> new HTMLDivElement({...}, ...)
>>
>> The reason this is nice is that if you mistype the element name, you
>> get an error message much closer to the typo. It would be nicer still
>> if the constructors names were short, eg Div instead of
>> HTMLDivElement.
>>
>> Needless to say, HTMLElement.create is useful like
>> document.createElement is useful, for creating unknown elements or for
>> reflecting on tag names (although the .constructor property could be
>> used for that instead.)
>>
>>> Can you give some proper examples where Element.create() makes DOM
>>> generation simpler? I've only seen vague hand-waving up to now.
>> To me I think this:
>>
>> document.body.appendChild(new Div({className: 'warning'}, [new
>> Text('Danger, Will Robinson!']));
>>
>> Is preferable to this:
>>
>> var d = document.createElement('div');
>> d.className = 'warning';
>> d.textContent = 'Danger, Will Robinson!';
>> document.body.appendChild(d);
>>
>> The former is mercifully only four lines because of textContent; if it
>> contained markup, it would be even more verbose.
>>
>> Dominic
>>
>
> That's not a proper example, and anyway it would be much simpler to use:
>
> document.body.insertAdjacentHTML("beforeEnd",
>     '<div class="warning">Danger, Will Robinson!</div>');
>
> A proper example would be to show how the internals of a popular JS 
> lib would be refactored, or a significant example of DOM generation 
> such as a table.

Simply showing the same use in an popular JS lib should be sufficient. 
Why should we expect a lib to "refactor"?
They would still include their existing code path, but use the new 
method in the polyfill school of programming.

Having tried to push this Element.create concept for awhile, I've change 
my approach: I'd prefer to overload the JSON object.
If we had a -good- way of translating JS objects into DOM, we'd gain a 
lot. We'd gain XML serialization, we'd gain XSL and selectors.

More thought should certainly go into this: E4X has been vetoed by so 
many vendors that it simply can't be saved.
So lets save it through the JSON object.

JSON.toNode(object xmlForest)
JSON.toNode(DOMString jsonString)

That gets us serialization, appendChild / document fragments, chaining, 
and any other goodies that have been attached to the Node object.

It does not get us a means of converting XML to JSON, but I think it's a 
good start.

var myDiv = JSON.toNode({div: 'Hello World'});
myDiv.outerHTML == '<div>Hello World</div>';

I'd really like to avoid the "use case" debate. In the time I've been 
posting to these standard lists, I've found that there is no 
accountability on the part of the judges, when it comes to deciding the 
qualities of "use cases". I'm happy to provide them, because I think 
they're darn useful.

Debating "use cases" as a means to weigh whether or not a technical 
feature should be considered is not something I'm interested in.
I don't think it's a defensible technique. There are no ways to falsify 
or otherwise prove criteria. It's subjective. I certainly feel subjected 
to cruelty when I go through it.

At least the Change Proposal process has some scientific merit.

Back to JSON.toNode. Let's make it easy on all of us. If typeof is a 
string, it's a text node, if typeof is an object, it's an element and
if we can get consensus, we can look at extending that model.

JSON.toNode({div: { 'hello': 'world' }}).outerHTML == 
'<div><hello>world</hello></div>';

-Charles

Received on Saturday, 1 October 2011 02:15:23 UTC