F2F/Auckland 2011/SVGXxxList-issues
Object identity given indirect changes
test (Read the following first.)
SVGAnimatedXxxList and SVGXxxList identity
A given base value list object must not be the same object as its corresponding anim value list object, regardless of whether the corresponding attribute is being animated or not.
Whenever scripts get a given SVGAnimatedXxxList or SVGXxxList object from an element, they must always be given the exact same object throughout the entire life of the document. (Implementations may in practice return a different (new) object for successive gets, just so long as script cannot detect that the object is different to the object returned by a previous get. In practice this means that script must not have references to the object or any of the objects it "contains", if it has any.)
SVGXxx list item identity
An item at a given index in a base value list must be a different object to the object at the same index in the corresponding anim value list, regardless of whether the corresponding attribute is being animated or not.
Whenever scripts gets an SVGXxx list item at a given index from an attribute's SVGXxxList object, it must always be given the exact same object throughout the entire life of the document except under the following circumstances.
- The SVGXxxList interface is used to replace/move an item.
- Implementations may in practice return a different (new) object for successive gets, just so long as script cannot detect that the object is different to the object returned by a previous get. In practice this means that script must not have references to the object or any of the objects it "contains", if it has any.
While the length of a list may change under the following circumstances, any item that was previously at a given index must continue to be the item at the given index (so long as that index is still valid for the new list length), even when:
- A new animation sample value is set.
- An animation overriding the baseVal begins.
- An animation overriding a lower sandwich animation begins.
- An animation repeats.
- A frozen animation ends.
- fill=freeze is removed from a frozen animation.
- The underlying attribute is changed (e.g. by a setAttribute call), whether or not the underlying attribute is being animated.
In other words implementation should only ever remove excess items, regardless of what changes the list.
One justification comment: presumably we don't want to have animation samples wipe animVal list items!! So it seems like setAttribute shouldn't either. (Mozilla can't tell when a new animation starts overriding an existing animation.)
If we were to remove baseVal list items when setAttribute is called, we should probably remove animVal items too if the animated value currently depends on the baseVal.
Inserting list items via SVGXxxList interfaces
This section is about inserting items into a list using the four methods initialize, insertItemBefore, replaceItem and appendItem.
Inserting items that belong to a non-list attribute
This is a bit of a special case. We can't "remove the item from its existing list", since the attribute it belongs to is not a list! Seems like an oversight in the spec. We could:
- Clone
- Throw
(Allowing the item to belong in multiple places would preclude tearoff optimizations, and result in confusing behavior for users, so I'm not seriously considering that option. Also nobody does that.)
Other cases
When the given list item does not already belong to an attribute, then it itself is inserted into the list. If the given item is already in a list - including this list (for consistency) - then a clone of the item is inserted rather than the given item. In the case of replaceItem(), this is the case even if the inserted item is the item at the specified index (again, for consistency).
unowned item test
owned item test
Mutability
baseVal lists and their items are mutable, animVal lists and their items are not.
Once items are removed from a list the are mutable, whether they were removed from a baseVal or animVal list.
Recycling list items
If a list item is removed from a list, the implementation may only recycle the object if there are no existing references to it.
Misc
Detached SVGLength items are not going to be able to resolve percentage values or certain other units to user units. What error should we throw if the user tries to read the user unit value from such a length?