Deferring SVG DOM to a separate module

I've had a few conversations the past few weeks about the SVG DOM methods,
their potential, and their limitations.  I had been meaning to write up a
proposal for discussion prior to the start of the F2F this week, and I'm
sorry I could not find time to do that (among other things I was hoping to
tidy up).

After looking at the actions from the first day of that meeting [1], I
think it is all the more important.

Yes, the PathSeg interfaces are over-complicated and under-used.  But is
the best solution to dump them without a replacement?

Yes, the various transformation-related functions should be removed from
SVG -- but only because they should be generalized in a way that applies to
all transformable elements.  Removing this very useful functionality, that
works in most cases, because there are new undefined edge cases, seems
counter-productive.

The DOM side of the SVG specifications need a lot of work.  It needs work
on existing problems with the SVG 1.1 specs, and it needs work because of
new complications that we are introducing, by turning structural attributes
into presentation attributes and by extending SVG features to other element
types.  Furthermore, it needs to be coordinated with the DOM Geometry
interfaces spec.

I do not want the desire to finalize SVG 2 to result in the gutting of SVG
DOM, without any replacement or fallback deprecation strategy.  If there
isn't the will to buckle down and fix them this year, can we at least
separate them into their own module that can be addressed in due course?

I was under the impression that the SVG Working Group had made a commitment
that SVG 2 would be backwards compatible.  All valid SVG code would still
be valid.  Yet repeatedly when it comes to SVG DOM there has been no
hesitation of introducing breaking changes.

I know that these features aren't used a lot.  Most developers don't know
they exist.  If they do, they quickly discover how unreliable browser
implementations are.  In commonly used JS libraries, authors generally have
written their own code (that depends only on Core DOM get/set attribute
methods) in order to have consistent behavior.  But those are all arguments
for fixing the spec, not tossing it out.  When CSS is moving toward greater
transparency and author access to browser computations, it seems tragic to
move in the opposite direction in SVG.

The few developers who are making use of the SVG DOM functionality are
SVG's greatest advocates.  If you keep pulling the rug out from under them,
well, see other threads relating to SMIL for evidence of how that tends to
pan out.  This includes myself.  We were discussing keyboard navigation at
the Accessibility Taskforce last week, and the question came up of how
could a script quickly find the relative positions of two elements on
screen, irrespective of transforms.  Oh, that's easy, I said, there's this
wonderful little function called getTransformToElement.  How can anyone
expect to build upon SVG functionality knowing that fundamental methods
such as this might disappear at any moment?

To the rest of the WG, I'll check in to IRC around 16:00 CEST Wednesday if
you would like a more detailed discussion of this.  Please don't break
anything new before then.

All the best,
Amelia

[1]: http://www.w3.org/2015/06/09-svg-minutes.html#ActionSummary