W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: [DOM4]: Element.create

From: Sean Hogan <shogun70@westnet.com.au>
Date: Sat, 01 Oct 2011 23:48:35 +1000
Message-ID: <4E871A33.9070200@westnet.com.au>
To: Charles Pritchard <chuck@jumis.com>
CC: Dominic Cooney <dominicc@chromium.org>, www-dom@w3.org
On 1/10/11 12:15 PM, Charles Pritchard wrote:
> 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"?

I don't expect JS libs to ever refactor, for reasons I have listed 
previously. But the exercise of refactoring would be instructive as to 
how useful (or not) the feature is.

> 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.

You'd have to talk to the Ecmascript designers about the JSON object.

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

what would the following result in?

     var myFrag1 = JSON.toNode({b: "Hello", i: "World"});

     var myFrag2 = JSON.toNode({b: "Hello", b: "World"});


how would I create equivalents of the following?

<div>Hello <b>World</b>!</div>

<div class="greeting">Hello <b class="target">World</b>!</div>

Sean
Received on Saturday, 1 October 2011 13:49:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT