Re: Element.createElement proposal
Johnny Stenback <[email protected]>
| Newsgroups | gmane.comp.mozilla.devel.dom |
|---|---|
| Message-ID | <[email protected]> |
On 08/05/2009 01:52 AM, 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} );
>
I still think element creation belongs on document objects more than it
does on elements. How about adding a createSVGElement method to our
documents instead? Since it'd be a new method, we could change the
signature of that to do things that are more developer friendly? Given
that HTML5 supports mixed in SVG, this would make some amount of sense
at least on HTML documents. Same goes for MathML too, I guess...
> 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.
>
> Thoughts?
>
> Jonathan
>
--
jst