Re: [dom] Comments on heycam's new SVG DOM

On Thu, Aug 8, 2013 at 4:36 PM, Cameron McCormack <> wrote:
> Tab Atkins Jr. wrote:
>> Some comments on the proposal at
>> <>.
>> 1. The proposal currently says that SVG elements in either HTML or the
>> null namespace opt into the new DOM.  This appears to be because of a
>> belief that createElement() run in an XML document creates an element
>> in the null namespace.  Per spec, at least, this is wrong -
>> createElement() always puts elements in the HTML namespace, so we can
>> just drop the "null namespace" part and only care about the HTML
>> namespace.
> As I saw it, there were two advantages to allowing the elements to be in
> either the HTML namespace or no namespace.  One is createElement doing the
> right thing, regardless of whether you were in an HTML or XML document,
> though as you point out if it's meant to put things in the HTML namespace
> always, then that's one advantage removed.  The second was to allow
>   <graphics>
>   </graphics>
> in image/svg+xml documents, rather than requiring
>   <graphics xmlns="">
>   </graphics>
> (Or <svg>, if you don't buy in to the need for a new root element.)

Ah, I didn't think of that.  Stupid XML rules. >_<

>> 3. I'm not convinced on the<viewport>  element.  I have found it
>> slightly clumsy before that some attributes are only useful on the
>> root<svg>  and others are only useful on nested<svg>s, but I don't
>> know how bad this is.  Shrug, I can be convinced either way.
> Three alternatives to <viewport>: continue allowing <svg> as the viewport
> establishing element inside an SVG fragment; allow <graphics> in the middle
> of the document; add the viewport-defining attributes to <g>.

The third one, please!  I usually just set "svg svg { overflow:
visible; }" in my stylesheet and then just use <svg> as a movable <g>
anyway. (Easier to use x/y than transform="translate(x,y)" all the


Received on Thursday, 8 August 2013 23:42:49 UTC