Re: [svg-tests] Convert SVG 1.1 marker tests to reftests. (#4015)

Review for accuracy per Spec:

- **marker-001.svg** Nothing controversial here & nothing changed

- **marker-002.svg** A little more complicated (IE fails this test) but all to spec & nothing new.  One concern, though: I'm noticing visible differences in anti-aliasing, in multiple user agents, between the marker test and the reference for the marker with stroke.  It's slight, but probably enough to make automated tests flaky.  The issue is that the stroke extends outside the viewBox of the marker, and so it being clipped by hidden overflow. The reference re-creates the effect with a clip-path, but there are also differences in coordinate systems that seem to be creating rounding differences. It may be possible to get a closer match by using nested `<svg>`, with `viewBox` and hidden overflow, instead of transforms and clip-path.

- **marker-003.svg** and **marker-004.svg**These are rather complex-looking tests for what they are testing (that the shorthand property works), but all looks okay.

  *Aside:* Is there a way to note test dependencies in the WPT metadata? E.g., marker-003-ref.svg uses the basic marker presentation attributes as a reference for the CSS test, so it is dependent on basic marker support (i.e., marker-001.svg passing).  A user agent that doesn't support markers at all would get a false positive here.

- **marker-005.svg** I had to look up this one to see whether we'd changed it.  ***The reference SVG is wrong for `overflow: auto`. It should match `visible`.*** @nikosandronikos can you make the change?

  Also, I'm again seeing slight anti-aliasing differences between the test and reference files. In this case, the clipping effect has been applied by actually modifying the underlying paths to match the clipped shape. In this case, I'd be a bit worried about replacing it with `<svg>` with hidden vs visible overflow, in fear of false positives (e.g., visible overflow being broken for both `<svg>` and `<marker>`)

- **marker-006.svg** The third sub-test in this file (the auto-orientation one) seems to be identical to the equivalent sub-test from marker-001.svg  It isn't using offset viewBox values, which this file is supposed to be testing. Not sure whether that's a problem from the SVG 1.1 test suite copied over, but either way it would be nice to make it actually test something new.

- **marker-007.svg** This one is correct & to spec in both SVG 1.1 and SVG 2, despite failing in both Edge (partly) and Firefox (completely).

- **marker-008.svg** The comment with the test description is no longer correct in SVG 2. (These are *not* the only markable elements).  The test is correct, for what it tests. Anti-aliasing discrepancies again.


I'd be okay approving the changes with the one correction to marker-005.svg.  However, maybe some browser devs could run these through their testing systems to see if the anti-aliasing differences are causing false failures.  If so, some fussing may be required.

And of course, there are *new* marker features that we need to add tests for.  And lots of old edge cases that these don't cover.

View on GitHub: https://github.com/w3c/web-platform-tests/pull/4015#issuecomment-259871163

Received on Friday, 11 November 2016 03:16:37 UTC