Re: Deferring SVG DOM to a separate module

A follow-up, based on the conversation I had today with the team working at
the F2F meeting:

Everyone seemed to agree that SVG DOM needs work, and this work should move
forward in coordination with CSS OM work.  Until that happens (and it is
not likely to happen before the rest of SVG 2 is finalized), the current
DOM will mostly stay the same, with a few changes to make it easier for
implementers to move forward with other SVG 2 changes.

In other words, work on improving DOM will be deferred to 2.1 or something
like that, but it won't be separated into a different spec.

For now, one specific change we discussed was neutering "animVal" so that
it is always an exact synonym for "baseVal".  From the implementation side,
this makes it much easier to move forward with web animation optimizations
on a separate thread, if they don't have to keep updating data accessible
from the main thread.  If you know of current content (something more than
"look what you can do" demos) that depends on animVal giving the current
animated value, speak up soon.

I am assuming that web animations will offer an alternative, thread-safe
way of accessing this information (e.g., when an animation is
paused/interrupted because of user action, you need to figure out where
everything currently is before setting up a new animation), but I'm not
sure how this would work (maybe by passing a specific time value to the
animation, instead of asking for "current value"?).

We didn't actually discuss getTransformToElement in detail.  Can we keep
it, but with a warning that behavior is undefined if the two SVG elements
do not share a common (<svg>) farthestViewportElement?

~ABR