W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2010

tests that differentiate between SVG 1.1 Tiny, Basic and Full

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 10 Dec 2010 13:08:58 +1300
To: public-svg-wg@w3.org
Message-ID: <20101210000858.GD11474@wok.mcc.id.au>
Take for example struct-cond-03-t:


This test will render differently depending on whether feature strings
corresponding to features required by SVG 1.1 Full implementations are
supported.  You can see that in the reference image, Batik supports
"http://www.w3.org/TR/SVG11/feature#SVGDOM", which causes the top
rectangle to say “This viewer does more than SVG Tiny” and for its
colour to be different.

We are not caring about SVG 1.1 Tiny and Basic now (right?).  Should the
test be allowed to pass if it does not support that SVG 1.1 Full feature

My preference would be to change any tests that pass if Tiny or Basic
functionality is supported but Full functionality is not.  For example,
I just changed struct-dom-06-b:


The pass criteria used to be:

  If an implementation supports the ECMA Script DOM binding, then the
  image should show the following text: "The DOM API is supported".
  Otherwise, the following will show: "Removing DOM elements is not
  supported", and the background will be red. 

and I changed it to:

  The test passes if the text "DOM API is supported" is shown, the text
  "Removing DOM Elements is not supported" is not shown, and no red is

(I would actually prefer it if all feature string support tests were in a
single test file.  People do look at numbers-of-tests-passed in test
suites, and having a number of tests that would fail if particular SVG
1.1 Full feature strings are not supported I think would “punish”
vendors for attempting to be more accurate with their feature string

Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 10 December 2010 00:09:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:44 UTC