Re: Element.createElement proposal

On 2009-08-11 1:27 AM, Jonas Sicking wrote:
> Jonathan Watt wrote:
>> Hi guys,
>>
>> I've been thinking about what we can do to simplify the creation of new elements
>> using the DOM. I came up with a few ideas in the SVG WG, and I wondered what you
>> think about the following one (and how implementable it is in Mozilla). Please
>> bear with me to the end of the email.
>>
>> It's really tedious and error prone that you have to do:
>>
>>   c = document.createElement('NS-people-dont-know-or-want-to-type', 'circle');
>>   c.setAttribute('cx', '10');
>>   c.setAttribute('cy', '10');
>>   c.setAttribute('r', '10');
>>   svgElement.appendChild(c);
>>
>> Much better would be:
>>
>>   c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
>>   svgElement.appendChild(c);
>>
>> or even just:
>>
>>   c = svgElement.createChild('circle', { cx: 10, cy: 10, r: 10} );
>>
>> Basically, we'd add a createElement method to the Element interface, have it
>> create the new element in the same namespace as the element on which it's
>> called, and allow an (optional) JS object literal to be passed in to specify
>> attributes.
>>
>> Apparently WebIDL will allow us to have optional arguments (for the attributes
>> argument) and to have PropertyBag type interfaces that ECMAScript bindings could
>> allow JS object literals to be substituted for. So it seems this could be done
>> spec-wise.
>>
>> To avoid differences with the createElement method on the Document interface, it
>> would seem desirable to make the Document version behavior in a similar way with
>> regards to namespaces. HTML5 changes the behavior of Document.createElement to
>> always make it create an element in the HTML namespace (instead of the null
>> namespace) when called on an HTML document, so I was wondering if we could do
>> the same for SVG documents. At that point though, it seems like a cleaner and
>> more consistent solution would be to simply say that Document.createElement
>> creates an element in the same namespace as the document element (or null only
>> if it doesn't have a document element).
>>
>> So it seems to me that the changes proposed are highly desirable from the user's
>> point of view, and that they're also specifiable. I guess it just comes down to
>> whether changing Document.createElement in this way would break much content
>> (doubtful since we'd be talking about non-HTML content?), and whether it's
>> implementable. Even if it would break small amounts of content, maybe it's worth
>> it if it's a solid step towards resolving the "namespaces are a nightmare" issue.
> 
> It's certainly implementable. Not sure when the property-bag thing would 
> happen, but I suspect it's something that other interfaces could use as 
> well.

Such an a setAttributes (plural) method so you don't have to have multiple
setAttribute lines.

> In general I like the idea, but not sure how highly I would prioritize 
> it. And I would want to run this past other browser vendors to make sure 
> that they agree with. Unfortunately I don't think that w3c has any plans 
> to work on DOM-Core, so I'm not sure that we could get a formal spec on 
> this anytime soon.

Since the WebApps WG is taking on DOM 3 Events, maybe they could take on some
changes to DOM Core too?