[dom] Comments on heycam's new SVG DOM

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.

2. I like the new root element.  It's a bit clearer for the purpose of
pretending that SVG was always part of Greater HTML, and it's
interestingly analogous with <math>.  It also works well for the
standalone case.  I agree that we need something unalterable in the
element to opt in, and tagname is a good candidate for that.

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.

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

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

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.

Something like this, I guess.

~TJ

Received on Thursday, 8 August 2013 22:26:19 UTC