W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2008

Behaviour of SVGLengthList.replaceItem() in existing UAs

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 19 Jun 2008 17:51:28 +1000
To: public-svg-wg@w3.org
Message-ID: <20080619075127.GA22416@arc.mcc.id.au>

For ACTION-2068, here are the results of some brief testing of
SVGLengthList.replaceItem() when the item to be insert is already in
the list.


The file does the following call:

  list.replaceItem(list.getItem(n), m)

with four sets of values for n and m:

  ▪ n = m, n < length - 1
  ▪ n = m, n = length - 1
  ▪ n < m
  ▪ n > m

Results (no interop here):

Batik nightly

  For all cases it behaves like:

    list.replaceItem(list.getItem(n), m)

  For the n = m = length - 1 case, a (non-DOM) exception is thrown.

  So the index is of the item to replace after the removal of the first

Opera 9.5

  For n = m, same behaviour as Batik.  (But for n = m = length - 1, an
  actual DOMException INDEX_SIZE_ERR is thrown.)

  For the other cases, the index is of the item to replace before the
  removal takes place.

WebKit nightly

  Seems to replace the actual value of a given item in the list.  So the
  number of items stays the same, but the value of the item at index m
  is set to the value of the item at index n.
Firefox 3

  replaceItem() isn’t implemented.

Renesis 1.1
  SVGTextElement.x isn’t implemented.

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 19 June 2008 07:52:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:08 UTC