W3C home > Mailing lists > Public > www-svg@w3.org > December 2013

Re: Relaxing SVGList* item object equality in Blink/Chromium

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 13 Dec 2013 22:11:52 -0500
Message-ID: <52ABCC78.2000203@mit.edu>
To: Dirk Schulze <dschulze@adobe.com>
CC: www-svg <www-svg@w3.org>, Rebecca Hauck <rhauck@adobe.com>
On 12/13/13 1:53 AM, Dirk Schulze wrote:
> Thanks a lot for the review Boris! We will investigate in the issues and submit the tests for a 2nd review.

Sounds great, thanks!

I did a bit more poking at the tests and found a few more issues:

1)  In svg-dom-gradientTransform-extended.html, 
svg-dom-patternTransform-extended.html, and 
svg-dom-transform-extended.html the testListItemUpdated test asserts 
that calling setScale() on an SVGTransform object changes the identity 
of the object returned from .matrix.  But the spec (both SVG 1.1 and SVG 
2) says:

   The matrix that represents this transformation. The matrix object is
   live, meaning that any changes made to the SVGTransform object are
   immediately reflected in the matrix object and vice versa.

which means that setScale on the transform is supposed to mutate the 
matrix, not create a new one.  This test should probably check that the 
matrix entries were as expected before and after the setScale call and 
that the object identity did NOT in fact change.

2) In svg-dom-transform-animval-mixed.html the test checks that 
testRect1 has one transform and testRect2 has two transforms, but the 
markup has no transforms on the former and one on the latter.

3) svg-dom-transform-styles.html seems to be checking that CSS 
transforms (but only prefixed ones and only for some prefixes?) affect 
the .transform DOM object.  That's certainly not the case in SVG 1.1, 
though there seems to be an open spec issue about whether it should be 
true in SVG 2.  Not sure which spec version the tests are targeting.

These tests also caught what certainly looks like a bug in Gecko, filed 
as https://bugzilla.mozilla.org/show_bug.cgi?id=950306

Received on Saturday, 14 December 2013 03:12:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:49 UTC