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

Tab Atkins Jr. wrote:
> Some comments on the proposal at
> <http://dev.w3.org/SVG/proposals/improving-svg-dom/>.
>
> 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="http://www.w3.org/1999/xhtml">
   </graphics>

(Or <svg>, if you don't buy in to the need for a new root element.)

> 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>.

> 4. I strongly agree on the clean break between old interfaces and new.
>   There are too many things where we'd either need clumsy overloads, or
> do really bizarre subclassing, or just add new "good" names for
> attributes.  (For example, there's no non-hacky way to change rect.x
> or a.href to let you avoid the baseVal/animVal stuff.)

Per IRC discussion, we need to look into "value objects" from ES.next, 
to see if they might be able to solve this problem.  If they can, I 
wonder if that solves much of what this proposal aims to achieve.

> 5. I don't like the precise shape of the length/etc new stuff.  The
> functionality is great, but the API shape is different from what we
> were aiming towards for CSS, and is somewhat clumsy in some aspects
> (as you note in an issue).  We should just work together with CSSOM
> and define something consistent.  Maybe this is something for FXTF?
> (I don't care where it happens, I just want us to coordinate.)

I agree we should coordinate to have things represented the same as in 
CSSOM.

> For example, the CSSWG knows from experience that things which start
> out as simple values often expand later to become list-valued or
> map-valued, and shaped its proposal to allow for this kind of
> expansion in a natural way.  For example, list-valued properties
> actually return an object for just the first item, but with a .l
> property hanging off that returns the whole list.
>
> On a related note, one of the possible directions we've thought about
> for the CSSOM Values API was just defining all the values interfaces
> as subclassing DOMString, so you can still interact with the value as
> a string, but can also hang off properties like .px (for lengths) or
> .red (for colors).
>
> Taking these together, we can, for example, have .transform be a
> DOMString subclass.  I guess it has [PutForwards] on it so it can be
> set to a string directly.  It exposes the transform properties for its
> first item, and has a .l property on it to expose a (live?) list of
> transforms.

Also per IRC, I don't think this is a great way to go, unless value 
objects solve some fundamental problems with string-ish objects: you 
can't compare two string-ish objects for string equality using "==", 
since that would compare object identity, and "!" would always return false.

Received on Thursday, 8 August 2013 23:36:40 UTC