RE: [DOM4]: Element.create

These are interesting proposals. Two initial thoughts:

First, the static create API should probably be on HTMLElement to avoid ambiguity with other namespaces. I think we're not really interested in building a generic API for creating *any* element/namespace combination, just primarily HTML (or SVG/MathML) elements.

Second, the property bag for the second parameter might be awkward to use in some scenarios. If it is intended for content attributes, for example, the language for HTML attributes includes hyphens such as http-equiv  which must be quoted when specified in object literals. If it is intended for IDL attributes, then many of the range of available IDL attributes are read-only or complex objects (e.g., .style) that wouldn't make sense to specify in the property bag. 

This all seems so familiar... oh wait! This was IE's old behavior for createElement('<a href="url">').... The convenience was appreciated by a fair number of developers.


-----Original Message-----
From: [] On Behalf Of Anne van Kesteren
Sent: Thursday, September 15, 2011 11:17 AM
Subject: Re: [DOM4]: Element.create

On Thu, 15 Sep 2011 20:07:51 +0200, Charles Pritchard <>
> On webapps, we discussed a helper method, "create", which might fit 
> well in DOM4.

> l
> Element.create('img', {src: '...'}),

I'm not sure what the second argument should be in terms of Web IDL. It's basically an unconstrained dictionary, but we do not have that at the moment.

It's also unclear to me whether the second argument should set properties or attributes. Setting attributes would be consistent with the DOM model.  
Setting properties might be more convenient, but e.g. setting innerHTML complicates matters as there is also a third argument to Element.create to conveniently set children.

Anne van Kesteren

Received on Thursday, 15 September 2011 18:43:18 UTC