Re: Element.createElement proposal

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.

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.

/ Jonas