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

Re: Tests required for recent changes to SVG 1.1 Second Edition

From: Erik Dahlström <ed@opera.com>
Date: Thu, 28 May 2009 16:24:38 +0200
To: "Cameron McCormack" <cam@mcc.id.au>, public-svg-wg@w3.org
Message-ID: <op.uum8zcbndhsuf5@gnorps.linkoping.osa>
On Thu, 28 May 2009 09:16:21 +0200, Cameron McCormack <cam@mcc.id.au> wrote:

> Hello WG.
>
> I went through the list of changes for the errata that were already
> folded in, and the other small changes that have been made that aren’t
> captured in errata, and came up with a list of tests that we should
> make:
>
>   * Test that presentation attributes on elements that previously
>     disallowed them are recognised.  (Such as by using
>     getPresentationAttribute and getComputedStyle.)
...
>   * Test that style/class attributes on filter primitives that
>     previously didn’t allow them now have an effect, e.g. by
>     using SVGStylable::{style,className}, getComputedStyle and
>     changes to filter behaviour.

The above ones fit into the same generic category.

...

>   * Test that default value for contentScriptType is
>     application/ecmascript.  (Though I’m not sure what this would
>     actually test; default encoding of external scripts?  Do browsers
>     really want to do this rather than sniffing?)

The 'type' attribute doesn't decide the encoding in HTML5. What it's used for is deciding if the script is supported or not. HTTP headers, the BOM of the external script resource and the host document encoding may all also have some influence on the chosen char-encoding for external script resources.

@type is useful for ignoring unsupported script languages, so maybe that would be a simple test - verify that both "application/ecmascript" and "text/ecmascript" elements are executed and that e.g "foo/bar" is not.

I'll be doing tests for the filters module anyway sooner or later, so I can take the ones below here.

>   * Test kernelUnitLength on feSpecularLighting (since it is now
>     defined).  However there aren’t any tests at all for
>     kernelUnitLength on either of the lighting filter primitives (or on
>     feConvolveMatrix)!

Any ideas for good pass criteria for such tests would be welcome.

>   * Test that SVGFESpecularLightingElement::kernelUnitLength[XY] reflect
>     the correct values, and that changing them has an effect.
>
>   * Test animating @xlink:href on feImage.
>
>   * Test feComponentTransfer when transfer function elements are omitted
>     or repeated.  (There might actually be a test for this one already.)

Yes, http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-color-02-b.svg

>   * Test that SVGFEConvolveMatrixElement::in1 works.
>
>   * Test that @azimuth on feDistantLight is interpreted as clockwise.
>
>   * Test that @seed on feTurbulence is truncated towards zero.
>
>   * Test that color-interpolation-filters doesn’t cause a colour space
>     conversion on ‘in’ for feDisplacementMap.

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Thursday, 28 May 2009 14:25:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 May 2009 14:25:43 GMT