Re: [DOM4]: Element.create

On 21/09/11 1:25 AM, Charles Pritchard wrote:
> 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.
>>> 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.

OK, fair call. They have the benefit (as you point out) that they can be 
universally supported by patching Array.prototype. Since 
Element.create() is a static method it can also be universally used in 
the same way, such as:

$.create = Element.create || function() {
   // emulate Element.create

The same cannot be said for Element.prototype.create(), except for those 
libs that have no qualms about patching DOM APIs.

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

Can you give some proper examples where Element.create() makes DOM 
generation simpler? I've only seen vague hand-waving up to now.


Received on Wednesday, 21 September 2011 00:40:58 UTC