Re: [Fwd: ACID3 test submissions]

Jonathan,

I agree that so far the Acid3 test is less easy to interpret than
Acid2, but Acid3 is not being written by the SVG WG, it is being
written by Ian Hickson (HTML/CSS WG).  If you have issue with the
ultimate presentation of the test, I suggest you contact him and offer
suggestions..

The key focus of the test is on JavaScript and DOM manipulation in
modern browsers (if I understand things correctly) - it is not
SVG-focused, but Ian is requesting some additional tests from the web
dev community.   The SVG WG has wisely come up with some good
examples.  However, they may or may not be picked to go into the final
test.  I guess Ian controls that...

Since you have a good handle on accessibility in SVG, might I suggest
that you, Jonathan, create a couple tests?  The rules are detailed
here: http://ln.hixie.ch/?start=1200301306&count=1

My own thoughts to the SVG WG:  I think it's great to get some
SVG-specific tests into the Acid3 test, and I'm glad this was done.
While Acid tests are no replacement for good test suites (which SVG
now has), they are good for symbolic representation of compliance to a
set of features, basically used as something like a marketing tool to
get competing browser implementations working towards something.
Since SVG is so huge, might I suggest that the SVG WG come up with
their own SVG Acid tests.  Something like (thinking out loud here):

- SVG Acid 1 Test - HTML harness covering most of the static SVG Tiny
1.1 features (simple shapes, stroke, fill, colors, text, text
selection, object/iframe/image inclusion, CSS background-image using
SVG)

- SVG Acid 2 Test - Test of SVG 1.1 declarative animation (could show
the test running next to a chunk of video or an animated GIF/PNG to
compare compliance)

- SVG Acid 3 Test - Test of SVG 1.1 Basic features (gradients,
rectangular clipping, opacity, text on a path)

- SVG Acid 4 Test - Test of SVG 1.1 Full features (DOM, filters, etc)

- SVG Acid 5 Test - Test of SVG Tiny 1.2 features (uDOM, Events,
solidColor, video, audio)

Constructing an Acid test is a bit of an art, I think - since you have
to pack a whole bunch of features into an ultra-simple representation.
 Again, these Acid tests should supplement the full test suites and
act, not as a replacement, but as only a symbolic nature of an
implementation's level of compliance.  In fact, the tests can include
a disclaimer with links to the full test suite.

Regards,
Jeff

On Jan 21, 2008 3:40 AM, "~:'' ありがとうございました。" <j.chetwynd@btinternet.com> wrote:
>
> Doug,
>
> well I loved the apparent overt simplicity of the Acid2 test.
> ie at least when launched any mortal could see if something was amiss.
>
> I'd prefer something less overtly technical and 'standards' in your
> face.
> something amusing that appealed to a wider audience, raising the
> popularity of SVG.
> A short story perhaps.
>
> It seems the test halts, could it not be designed to complete
> sections and continue in any case?
>
> Could accessibility tests to be included, including mousewheel,
> keyboard etc.
>
> xmlhttprequest and more....
>
> on this basis Acid 3 appears to fail to live up to Acid 2.
> it's not amusing, nut none the less a significant development.
>
> Might a short youtube animation be helpful in determining errors and
> generating interest.
>
> regards
>
>
> Jonathan Chetwynd
> Accessibility Consultant on Media Literacy and the Internet
>
>
>
>
> On 21 Jan 2008, at 05:46, Doug Schepers wrote:
>
> Hi, SVG Community-
>
> Given the popularity of the ACID tests for browser interoperability,
> we'd like to get some SVG tests in there for the next version.  A few
> of us on the SVG WG put together some tests, and I thought some of
> your might be interested in them as well.  I'm forwarding on  Erik
> Dahlstrom's explanatory email, with the tests attached.  If anyone
> has any suggestions for good SVG interoperability tests, either for
> the official ACID tests or for a dedicated "SVG ACID Test", feel free
> to let us know.
>
> I'll also blog about this on the W3C QA Blog [1], for those
> interested in some more details.
>
> [1] http://www.w3.org/QA/
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
>
> -------- Original Message --------
> Subject: ACID3 test submissions
> Date: Sun, 20 Jan 2008 23:02:57 +0100
> From: Erik Dahlstrom <ed@opera.com>
> Organization: Opera Software
> To: ian@hixie.ch
> CC: w3c-svg-wg@w3.org <w3c-svg-wg@w3.org>
>
> Hello Ian,
>
> see attached files for a submission of svg tests for the ACID3 test
> competition. The tests have been added to the acid3 framework as
> tests 65
> - 69.
> Comments and links to relevant parts of the SVG spec have been
> included in
> each subtest in the framework.
>
> The acid3-framework.html is a modified version of the unfinished
> draft of
> ACID3[1], with a few minor modifications:
> a) there is an <object> element that references an svg
> b) there is an <iframe> element referencing the same svg
>
> These two ways of referencing svg should both work, and there is a test
> that checks this (#69).
> In addition to this one svg file (empty.svg) which contains a few
> lines of
> helper code, it in turn references an external svgfont file
> (acid3font.svg). This is intentional to test that external svgfonts are
> supported (#67).
>
> Brief comments about each test:
> #65: This test is meant to be a very basic test for declarative (SMIL)
> animation in SVG.
>
> The test begins by creating a few elements, among those is a <set>
> element. This element is prevented from running by setting
> begin="indefinite", which means that the animation doesn't start
> until the
> 'beginElement' DOM method is called on the <set> element. The
> animation is
> a simple animation that sets the value of the width attribute to 0. The
> duration of the animation is 'indefinite' which means that the value
> will
> stay 0 indefinitely. The target of the animation is the 'width'
> attribute
> of the <rect> element that is the parent of the <set> element. When
> 'width' is 0 the rect is not rendered according to the spec[7].
>
> Some properties of the SVGAnimatedLength[2] and SVGLength[8] are also
> inspected. Before the animation starts both baseVal and animVal contain
> the same values[2]. Then the animation is started by calling the
> beginElement method[9]. To make sure that time passes between the
> triggering of the animation and the time that the values are read out
> (in
> test #66), the current time is set to 1000 seconds using the
> setCurrentTime method[10].
>
> #66: This test checks the results of test #65, to check that the animVal
> syntax is supported and working.
>
> About animVal[2]: "If the given attribute or property is being animated,
> contains the current animated value of the attribute or property, and
> both
> the object itself and its contents are readonly. If the given
> attribute or
> property is not currently being animated, contains the same value as
> 'baseVal'."
> Since the duration of the animation is indefinite the value is still
> being
> animated at the time it's queried. Now since the 'width' attribute was
> animated from its original value of "100" to the new value of "0" the
> animVal property must contain the value 0.
>
> #67: This test tests that external SVGFonts are supported.
>
> SVGFonts are described here[3], and the relevant DOM methods used in the
> test are defined here[4].
> Note that in order to be more predictable the svg should be visible
> (which
> it is in this framework), so that clause "For non-rendering
> environments,
> the user agent shall make reasonable assumptions about glyph metrics."
> doesn't influence the results. The font-size 4000 was chosen because
> that
> matches the unitsPerEm value in the svgfont, which makes it easy to
> check
> the glyph advances since they will then be exactly what was specified in
> the svgfont.
>
> #68: Tests that textPath in svg is supported by checking that the
> getRotationOfChar DOM method works.
>
> The getRotationOfChar[4] method fetches the midpoint rotation of a glyph
> defined by a character (in this testcase there is a simple 1:1
> correspondence between the two). The path is defined in the empty.svg
> file, and consists of first a line going down, then followed by a line
> that has a 45 degree slope and then followed by a horizontal line. The
> length of each path segment have been paired with the advance of each
> glyph, so that each glyph will be on each of the three different path
> segments (see text on a path layout rules[5]). Thus the rotation of the
> first glyph is 90 degrees, the second 45 degrees and the third 0
> degrees.
>
> #69: Tests that the getSVGDocument interface[6] is available on the
> <object> and <iframe> elements.
>
> GetSVGDocument[6]: "In the case where an SVG document is embedded by
> reference, such as when an XHTML document has an 'object' element whose
> href (or equivalent) attribute references an SVG document (i.e., a
> document whose MIME type is "image/svg+xml" and whose root element is
> thus
> an 'svg' element), the SVG user agent is required to implement the
> GetSVGDocument interface for the element which references the SVG
> document
> (e.g., the HTML 'object' or comparable referencing elements)."
>
> The method is called and then compared to the contentDocument attribute.
>
> ===
>
> Results from running the tests 65-69:
>
> Firefox 3.0 nightly (Gecko/2008011604 Minefield/3.0b3pre):
> Test 65: getSVGDocument not supported.
> Test 66: Failed to find <rect> element in svg document.
> Test 67: expected 4776, got: 2776 - getComputedTextLength failed.
> Test 68: expected 90, got: 0 - getRotationOfChar(0) failed.
> Test 69: getSVGDocument missing on <object> element.
>
> Webkit nightly (r29673):
> Test 65: SMIL::ElementTimeControl not supported.
> Test 66: expected 0, got: 100 - Incorrect animVal value after svg
> animation.
> Test 67: expected 4776, got: 5550 - getComputedTextLength failed.
> Test 68: expected 90, got: 0 - getRotationOfChar(0) failed.
> Test 69: getSVGDocument missing on <iframe> element.
>
> Cheers
> /Erik
>
> [1]
> http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html
> [2] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGAnimatedLength
> [3] http://www.w3.org/TR/SVG11/fonts.html
> [4] http://www.w3.org/TR/SVG11/text.html#InterfaceSVGTextContentElement
> [5] http://www.w3.org/TR/SVG11/text.html#TextpathLayoutRules
> [6] http://www.w3.org/TR/SVG11/struct.html#InterfaceGetSVGDocument
> [7] http://www.w3.org/TR/SVG11/shapes.html#RectElement
> [8] http://www.w3.org/TR/SVG11/types.html#InterfaceSVGLength
> [9] http://www.w3.org/TR/SVG11/animate.html#DOMInterfaces
> [10] http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement
>
> --
> Erik Dahlstrom, Core Technology Developer, Opera Software
> http://my.opera.com/macdev_ed
>
> -- <empty.svg><acid3font.svg>
> Acid3
>
>
>
>
>
>
> JS/?
>
>
> FAIL
> To pass the test, a browser must use its default settings, the
> animation has to be smooth, the score has to end on 100/100, and the
> final page has to look exactly, pixel for pixel, like this reference
> rendering.
>
> Scripting must be enabled to use this test.
>
> <empty.png>
> <!DOCTYPE HTML><html><head><title>FAIL</title><style>
> <!-- this file is sent as text/html, not text/css, which is why it is
>       called "empty.css" despite the following lines -->
>
>    body { background: white; color: black; }
>    h1 { color: red; }
>
> </style><body><h1>FAIL</h1></body></html>
>
>
>

Received on Monday, 21 January 2008 16:34:38 UTC