Re: Element.createElement proposal

Jonathan Watt wrote:
> 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?

Yes, it's definitely WebApps WG turf, but currently WebApps isn't 
chartered to revise DOM-Core.

/ Jonas