SVG DOM basic data types, feature requests

I've been working on a script to generate regular polygons from a
simplified markup notation. (
http://codepen.io/AmeliaBR/pen/AzvFt?editors=101)

Comments are welcome on that, of course, but this feature request relates
to some gaps in the basic DOM methods for manipulating SVG datatypes.  In
particular:

   - There is no way to dynamically create any of the SVGXXXList data
   objects, nor any of the SVGAnimatedXXX data objects.

   - There is no way to use relative units on dynamically created SVGLength
   objects.

On the first point, are there any plans to create constructors for the
lists or animated types?  For lists this would be straightforward.  For
animated types, it's useful for consistency, and would be especially useful
if the SVGAnimatedLength is extended to include the proposed unit
conversion accessor functions.

On the second point, this has been raised by Cameron McCormack in 2009 and
is recorded as  ISSUE-2217 (
http://www.w3.org/Graphics/SVG/WG/track/issues/2217), but no action has
been recorded.  Also ISSUE 2406 is a partial duplicate

I was wondering if there were any active plans or proposals to move forward
that?

Are there any expected implementation problems from having methods to get
and set the context element or the directionality (which would probably be
defined through a new enum as X,Y, or OTHER) of a length?

Would there be implementation or backwards compatibility issues with having
an SVGLength generated using the `createSVGLength()` method of an
SVGSVGElement automatically use that element as its default context?  I.e.,
it would use that <svg>'s viewbox to define percentages and use its font
values.  Directionality would be "other" by default.

_______________________________________

A bit of context:
As it currently says in the SVG2 Editor's Draft,

An SVGLength <https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength>
object
can be *associated* with a particular element, as well as being designated
with a *directionality*: horizontal, vertical or unspecified. The
associated element and the directionality of the length are used to resolve
percentage values to user units. Unless otherwise described, anSVGLength
<https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength> object is not
associated with any element and has unspecified directionality. (
https://svgwg.org/svg2-draft/types.html#InterfaceSVGLength)


In other words, the definition of relative length units (em, rem, ex, ch)
depends on the computed font-size of the element the length is associated
with.  The definition of a percentage length depends on both the nearest
viewport of that element and on whether this is an x/cx/width length, a
y/cy/height length, or something else (such as a radius).

All implementations of the SVG DOM must have internal ways of associating
the style context and directionality.  However, there is no way for the
author of a script to do so.  In SVG1, there is also no defined error
handling when attempting to use relative units without a style context
(Chrome returns a "NotSupportedError" for relative units, Firefox gives me
"NS_ERROR_FAILURE" even for absolute units).

The current SVG2 draft addresses some of the error cases (it suggests that
percentages should be converted to user units when a context is not
defined), but not all (no mention of default font metrics).

Searching the list archives, the only other relevant discussion I found was
a suggestion from 2012 to use a (proposed, not implemented) CSS length
interface as a superclass for SVGLength (
http://lists.w3.org/Archives/Public/www-svg/2012Sep/0065.html), which would
return `null` for any relative units or percentages.  That proposed
interface didn't make it into CSS Values & Units 3, and CSS animations
currently doesn't have any way to access base versus animated values, so I
think SVG should really lead rather than follow in standardizing these DOM
features.

I know these changes wouldn't be as widely used as the new unit accessor
functions for SVGAnimatedLength, but they are essential for expanding upon
base functionality.