Element.createElement proposal

[Jonathan Watt]

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.

Thoughts?

Jonathan

[Robert O'Callahan]

What about HTML5 SVG parsing? We want a solution that works well in an
HTML document.

So why not use the HTML5 parsing rules to determine which namespace the
element gets? The HTML5 parser already has a list of which elements
should be SVG or MathML.

Rob

[Jonas Sicking]

Post by Robert O'Callahan
What about HTML5 SVG parsing? We want a solution that works well in an
HTML document.
So why not use the HTML5 parsing rules to determine which namespace the
element gets? The HTML5 parser already has a list of which elements
should be SVG or MathML.

That was my initial reaction too. Unfortunately there is overlap between
HTML names and SVG names. Specifically both languages have an <a>,
<style> and <script> elements. And as I understand it SVG might get a
<textarea> too.

In the parsing algorithm which one to use is determined by context. I.e.
an <a> inside a <svg> will be a svg-a.

/ Jonas

[Robert O'Callahan]

Post by Jonas Sicking
That was my initial reaction too. Unfortunately there is overlap between
HTML names and SVG names. Specifically both languages have an <a>,
<style> and <script> elements. And as I understand it SVG might get a
<textarea> too.

Not on my watch.

Post by Jonas Sicking
In the parsing algorithm which one to use is determined by context. I.e.
an <a> inside a <svg> will be a svg-a.

Let HTML win.

Rob

[Jonathan Watt]

Post by Robert O'Callahan

Post by Jonas Sicking
That was my initial reaction too. Unfortunately there is overlap between
HTML names and SVG names. Specifically both languages have an <a>,
<style> and <script> elements. And as I understand it SVG might get a
<textarea> too.

Not on my watch.

Post by Jonas Sicking
In the parsing algorithm which one to use is determined by context. I.e.
an <a> inside a <svg> will be a svg-a.

Let HTML win.

I'm not at all keen on having such hidden gotchas.

[Jonathan Watt]

Post by Robert O'Callahan
What about HTML5 SVG parsing? We want a solution that works well in an
HTML document.
So why not use the HTML5 parsing rules to determine which namespace the
element gets? The HTML5 parser already has a list of which elements
should be SVG or MathML.

In addition to what Jonas says about tag name conflicts, making the DOM Core
spec use the HTML5 parsing rules would essentially be saying "screw you" to any
other languages that may have been using DOM Core for some time. Despite the
fact that the Web is the most important platform here, that doesn't really sit
well with me if we have a reasonable alternative, and I imagine that it'd meet
waaay more resistance. Using the same namespace as the element that the method
is called on makes it useful to all DOM consumers I think, and it's simple for
users to understand.

Jonathan

[Robert O'Callahan]

Post by Jonathan Watt
In addition to what Jonas says about tag name conflicts, making the DOM Core
spec use the HTML5 parsing rules would essentially be saying "screw you" to any
other languages that may have been using DOM Core for some time.

I wouldn't support changing any existing API behaviour. I would only add
new APIs like createChild. I'd probably call it something else, like
addChild.

Rob

[Jonas Sicking]

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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

[Jonathan Watt]

Post by Jonas Sicking

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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.

Post by Jonas Sicking
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?

[Jonas Sicking]

Post by Jonathan Watt

Post by Jonas Sicking

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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.

Post by Jonas Sicking
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

[Johnny Stenback]

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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...

Post by Jonathan Watt
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

[Jonathan Watt]

Post by Johnny Stenback

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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...

Hmm. I'm not all that keen on the idea of adding separate methods like
createSVGElement, createMathMLElement and createXULElement (and
createHTMLElement?) for each namespace we may support now or in the future.
Allowing elements to create more elements on the other hand is less of a problem
to me I guess.

Jonathan

[Johnny Stenback]

Post by Jonathan Watt

Post by Johnny Stenback

Post by Jonathan Watt
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.
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);
c = svgElement.createElement('circle', { cx: 10, cy: 10, r: 10} );
svgElement.appendChild(c);
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...

Hmm. I'm not all that keen on the idea of adding separate methods like
createSVGElement, createMathMLElement and createXULElement (and
createHTMLElement?) for each namespace we may support now or in the future.
Allowing elements to create more elements on the other hand is less of a problem
to me I guess.

I hear ya', and I'm not suggesting we do that for everything, only where
there's a real benefit to it, as I think is the case with SVG, given the
very complex DOM's you might find there.

What I don't like about svgElement.createElement() is that it seems a
bit odd to have to find an element to create one, which makes the case
where you're inserting SVG into a document where there is no existing
SVG such that developers still need to type out that namespace URI they
don't want to type out. svgElement.createChild() doesn't make any sense
to me as there's no child relationship between the element you use for
creating and the element that gets created.

Post by Jonathan Watt
Jonathan

[Zack Weinberg]

Post by Johnny Stenback
What I don't like about svgElement.createElement() is that it seems a
bit odd to have to find an element to create one, which makes the
case where you're inserting SVG into a document where there is no
existing SVG such that developers still need to type out that
namespace URI they don't want to type out. svgElement.createChild()
doesn't make any sense to me as there's no child relationship between
the element you use for creating and the element that gets created.

What's wrong with

var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root elt
var circle = svg.addChild('circle', {...}); // SVG 'circle'

? The same would work for <math>.

zw

[Johnny Stenback]

Post by Zack Weinberg

Post by Johnny Stenback
What I don't like about svgElement.createElement() is that it seems a
bit odd to have to find an element to create one, which makes the
case where you're inserting SVG into a document where there is no
existing SVG such that developers still need to type out that
namespace URI they don't want to type out. svgElement.createChild()
doesn't make any sense to me as there's no child relationship between
the element you use for creating and the element that gets created.

What's wrong with
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root elt
var circle = svg.addChild('circle', {...}); // SVG 'circle'

What should that code do if you replace parent.addChild('svg') with
parent.addChild('a')? And does this always append, or insert at the
beginning, what if I want to insert somewhere in the middle etc etc?

Post by Zack Weinberg
? The same would work for<math>.
zw

[Zack Weinberg]

Post by Johnny Stenback

Post by Zack Weinberg
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root
elt var circle = svg.addChild('circle', {...}); // SVG 'circle'

What should that code do if you replace parent.addChild('svg') with
parent.addChild('a')?

You get the HTML <a>. Does it *ever* make sense to have <svg:a> (or
<svg:anythingelse>) a direct child of <html:whatever>, rather than with
a <svg:svg> in between?

Post by Johnny Stenback
And does this always append, or insert at the
beginning, what if I want to insert somewhere in the middle etc etc?

I would expect "add" to mean appends, but I suppose you could have an
optional further argument which was either the element to insert after,
or magic constants for "at beginning"/"at end", like lseek().

zw

[Robert O'Callahan]

Post by Johnny Stenback

Post by Zack Weinberg

Post by Johnny Stenback
What I don't like about svgElement.createElement() is that it seems a
bit odd to have to find an element to create one, which makes the
case where you're inserting SVG into a document where there is no
existing SVG such that developers still need to type out that
namespace URI they don't want to type out. svgElement.createChild()
doesn't make any sense to me as there's no child relationship between
the element you use for creating and the element that gets created.

What's wrong with
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root elt
var circle = svg.addChild('circle', {...}); // SVG 'circle'

What should that code do if you replace parent.addChild('svg') with
parent.addChild('a')?

For simplicity I would say that e.addChild should always inherit the
namespace of e.

Post by Johnny Stenback
And does this always append, or insert at the
beginning, what if I want to insert somewhere in the middle etc etc?

I think it should always append. The use cases for the other positions
are much fewer and can be handled with existing DOM APIs.

The common case here is canvas-like scenarios where you already have an
SVG container and you're adding a lot of shapes to it.

Rob

[Henri Sivonen]

Post by Robert O'Callahan

Post by Johnny Stenback

Post by Zack Weinberg
What's wrong with
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root elt
var circle = svg.addChild('circle', {...}); // SVG 'circle'

What should that code do if you replace parent.addChild('svg') with
parent.addChild('a')?

For simplicity I would say that e.addChild should always inherit the
namespace of e.

Post by Johnny Stenback
And does this always append, or insert at the
beginning, what if I want to insert somewhere in the middle etc etc?

I think it should always append. The use cases for the other positions
are much fewer and can be handled with existing DOM APIs.
What about HTML5 SVG parsing? We want a solution that works well in an
HTML document.
So why not use the HTML5 parsing rules to determine which namespace the
element gets? The HTML5 parser already has a list of which elements
should be SVG or MathML.

The HTML5 parsing rules depend on context. Also, rules like deciding
what to do with <font> only make sense in parsing.

However, I like the idea of addChild() and I like the idea of being able
to pass attributes as a JS object of key-value pairs.

I suggest the following (inspired by the HTML5 parsing algorithm but
simplified and XBL2 attribute support added):

* Element.addChild(name, attrs=null): Creates an element in the same
namespace as |this| with the local name /name/. If attrs is not null,
adds attributes to the newly-created element as described below. Appends
the newly-created element as the last child of |this|.

- Exception: if |this| is in the http://www.w3.org/1999/xhtml
namespace or one of the elements that make the HTML5 parsing algorithm
allow HTML content: Behave like Document.createElement() below for the
element creation part.

* Document.createElement(name, attrs=null): If /name/ is "svg", creates
an element in the http://www.w3.org/2000/svg namespace with the local
name "svg". If the /name/ is "math", creates an element in the
http://www.w3.org/1998/Math/MathML namespace with the local name "math"
Otherwise, creates an element in the http://www.w3.org/1999/xhtml
namespace with the local name /name/. If attrs is not null, adds
attributes to the newly-created element as described below.

* Adding attributes extracts the key-value pairs from the JS object and
for each pair runs the following steps:
- If /key/ starts with "xml:", call
setAttributeNS("http://www.w3.org/XML/1998/namespace", key, value) on
the newly-created element.
- If /key/ starts with "xmlns:", call
setAttributeNS("http://www.w3.org/2000/xmlns/", key, value) on the
newly-created element.
- If /key/ starts with "xlink:", call
setAttributeNS("http://www.w3.org/1999/xlink", key, value) on the
newly-created element.
- If /key/ starts with "xbl:", call
setAttributeNS("http://www.w3.org/ns/xbl", key, value) on the
newly-created element.
- Otherwise, call setAttributeNS(null, key, value).

[Robert O'Callahan]

Instead of using a JS object, it's probably more performant, and I think
slightly more convenient, to just specify extra arguments:
e.addChild("span", "class", "hello", "style", "width:100px");
You can write it as
e.addChild("span",
"class", "hello",
"style", "width:100px");
if you like.

Rob

[Ted Mielczarek]

Post by Robert O'Callahan
Instead of using a JS object, it's probably more performant, and I think
e.addChild("span", "class", "hello", "style", "width:100px");
You can write it as
e.addChild("span",
"class", "hello",
"style", "width:100px");
if you like.

That strikes me as less intuitive, and it also doesn't match what existing
JS libraries like jQuery provide:
http://docs.jquery.com/Attributes/attr#properties
http://docs.jquery.com/CSS/css#properties

-Ted

[Mike Shaver]

On Wed, Oct 28, 2009 at 6:39 AM, Ted Mielczarek

Post by Ted Mielczarek

Post by Robert O'Callahan
Instead of using a JS object, it's probably more performant, and I think
 e.addChild("span", "class", "hello", "style", "width:100px");
You can write it as
 e.addChild("span",
            "class", "hello",
             "style", "width:100px");
if you like.

That strikes me as less intuitive, and it also doesn't match what existing
http://docs.jquery.com/Attributes/attr#properties
http://docs.jquery.com/CSS/css#properties

I agree -- having to count out the strings to build the pairings of
attribute and value seems error-prone, and it's pretty hard to build
the parameters for such a call programmatically.

Mike

[Jonas Sicking]

Post by Zack Weinberg

Post by Johnny Stenback
What I don't like about svgElement.createElement() is that it seems a
bit odd to have to find an element to create one, which makes the
case where you're inserting SVG into a document where there is no
existing SVG such that developers still need to type out that
namespace URI they don't want to type out. svgElement.createChild()
doesn't make any sense to me as there's no child relationship between
the element you use for creating and the element that gets created.

What's wrong with
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root elt
var circle = svg.addChild('circle', {...}); // SVG 'circle'
? The same would work for <math>.

In the original proposal this would only work if the element with id
"putsvghere" is an SVG element (which I take it was not the case since
you add an <svg> element into it).

/ Jonas

[Zack Weinberg]

Post by Jonas Sicking

Post by Zack Weinberg

Post by Johnny Stenback
What I don't like about svgElement.createElement() is that it
seems a bit odd to have to find an element to create one, which
makes the case where you're inserting SVG into a document where
there is no existing SVG such that developers still need to type
out that namespace URI they don't want to type out.
svgElement.createChild() doesn't make any sense to me as there's
no child relationship between the element you use for creating and
the element that gets created.

What's wrong with
var parent = document.getElementById("putsvghere"); // HTML elt
var svg = parent.addChild('svg'); // HTML5 'svg' elt = SVG root
elt var circle = svg.addChild('circle', {...}); // SVG 'circle'
? The same would work for <math>.

In the original proposal this would only work if the element with id
"putsvghere" is an SVG element (which I take it was not the case
since you add an <svg> element into it).

What I was trying to indicate with

// HTML5 'svg' elt = SVG root

is that creation of <svg> (or <math>) could magically switch that
element into the SVG (or MathML) namespace, just as in HTML5 parsing.

zw