Re: [DOM4]: Element.create

On 9/15/2011 11:42 AM, Travis Leithead wrote:
> 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.

Any interest in something like this:

as a shorthand for:
element.appendChild(document.createElementNS('....', '...'));

I do agree that Element.create should create an element within the HTML 
with necessary checks for SVG/MathML, if they are still necessary.

> 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.
Right, using cssText makes more sense than trying to support complex 
The read only values would do the usual, throw an error.

> 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.
IE custom elements and handlers, and <object> paint servers for CSS 
background images, were pretty cool, too.

> From: [] On Behalf Of Anne van Kesteren
> Sent: Thursday, September 15, 2011 11:17 AM
> To:
> Subject: Re: [DOM4]: Element.create
> On Thu, 15 Sep 2011 20:07:51 +0200, Charles Pritchard<>
> wrote:
>> 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 just an object, isn't it?

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

With children, might be nice to allow them as a second param, as well:

Element.create('tag', [ children, ... ])
Element.create('tag', {key: val, ...}, [ children, ... ])

I believe that chaining can be specified in web idl, such that this 
could work:


Received on Thursday, 15 September 2011 19:51:45 UTC