Re: Fwd: Minutes, SVG Telcon, 23 Nov 2009

Hi, Jeff-

Jeff Schiller wrote (on 11/25/09 2:17 PM):
>   <shepazu>  shepazu: Jeff may not have considered the issue of the
>   namespace of an element when he criticized using createElement as an
>   element method
>
> I assume you mean that createElement() as an element method would
> never need to have a namespace argument.  Yes, I can see that - but I
> still think that tweaking existing methods (createElement,
> createElementNS) is better than inventing new methods UNLESS you plan
> to have these new methods at the DOM Core level so that HTML coders
> can use them too (not sure if that was the intention).

My hope (and assumption) is that if the SVG WG, implementers, and 
community indeed decides that this approach is a good idea, then we 
would try to get this as a universal part of DOM Core.  Baby steps.


> Even then it will be harder to re-train people and will be confusing
> to tell them when to use Document.createElement() and
> Element.createElement().

It made more sense to me when the methods I defined (with different 
names) simply inserted the created element as a child of the element 
this method was called on.

But basically, the idea is that the newly minted element takes on the 
namespace of whatever node it was created on.  So, if you are trying to 
create an SVG element, and the root is an SVG document, you could use 
either Document or Element (on any of the SVG elements of the document); 
if the root is an HTML document, then you shouldn't use 
Document.createElement(), you should use Element.createElement() on one 
of the SVG elements (if any exist).

I don't think it's that complicated to understand... the created element 
is of the same "type" (namespace) as the element/document from which 
it's created.  createElementNS is retained to explicitly set the "type" 
if a suitable element doesn't already exist, but the NS syntax is 
error-prone and clumsy, so I'd like for authors to have to use it only 
when it's absolutely necessary.


> What I don't want though is different ways of creating SVG elements
> than creating HTML elements ... thus my leaning towards both existing
> techniques of innerHTML and document.createElement/NS.

Totally agreed.  We are looking at innerHTML's suitability for SVG and 
compound document content, in addition to HTML, and hopefully will be 
able to move forward on that soon.


Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Wednesday, 25 November 2009 19:38:51 UTC