W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2011

Re: [DOM4]: Element.create

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 20 Sep 2011 08:25:33 -0700
Message-ID: <4E78B06D.7050901@jumis.com>
To: Sean Hogan <shogun70@westnet.com.au>
CC: www-dom@w3.org
On 9/19/2011 9:50 PM, Sean Hogan wrote:
> On 16/09/11 4:07 AM, Charles Pritchard wrote:
>> On webapps, we discussed a helper method, "create", which might fit 
>> well in DOM4.
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0707.html
>>
>> Element.create('img', {src: '...'}),
>>
>> This included some talk about chaining the method, something that is 
>> present in several
>> JS libraries and particularly useful in cutting down on verbosity 
>> when building SVG documents and other graphs.
>>
>> It seems a reasonable discussion to continue here.
>>
>> This functionality has been requested across groups using DOM. 
>> Admittedly, it is syntactic sugar.
>>
>
> I can't imagine any scenario where people would switch to using this, 
> because:
>
> a) it won't be universally supported for some time. Meanwhile it is 
> just another feature to detect
> b) even when it is universal, the old methods will still be available
> c) it gives no appreciable performance boost
>
> Is there any precedent for js devs switching to a different API when 
> it isn't necessary and doesn't improve functionality or performance?

forEach, and many other array methods. They provide a standard API which 
can be used by polyfill style libraries.

A bit of sugar would be nice on procedurally generated DOM, especially 
more verbose standards like SVG.

> It won't affect people who use JS libs, so they won't care.
> I don't see why the JS libs would find it worth incorporating, and 
> people who write their own will feel the same.

JS libs have always been quick to do feature testing and implementation 
of new APIs.
I'm sure that JS libs that could be served, would incorporate it.

That said: patching the prototype chain is frowned upon in many JS style 
guidelines.
As an alternative, the JSON object is somewhat more -open- to hackery 
than the Element object.

JSON.createNode ( [optional] Namespace, [string], array, or object ) 
might spit out a DocumentFragment.

It may not be as handily accessed, but patching the JSON prototype chain 
is less intrusive, as the JSON object itself is rather simple.
A quick and standard manner of converting JSON strings and objects into 
DocumentFragment would be a nice, new feature.

parent.appendChild( JSON.createNode({img: { src: '...' }}) );
parent.appendChild(document.createElement('img')).src = '...';

The style has certainly been tried before, with various ideas on how to 
distinguish attributes, tag names, children and text content.

-Charles
Received on Tuesday, 20 September 2011 15:26:05 GMT

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