W3C home > Mailing lists > Public > public-test-infra@w3.org > July to September 2014

Re: Mismatch between CSS and web-platform-tests semantics for reftests

From: James Graham <james@hoppipolla.co.uk>
Date: Tue, 19 Aug 2014 17:21:04 +0100
Message-ID: <53F37970.6040008@hoppipolla.co.uk>
To: public-test-infra@w3.org
CC: fantasai <fantasai@inkedblade.net>
On 19/08/14 16:49, fantasai wrote:
> On 08/19/2014 03:01 AM, James Graham wrote:
> I'm not sure about tests using this feature currently, but there are
> some branches in the CSS spec that would warrant it. E.g. 'outline'
> can be painted at one of two places in the tree. Or letter-spacing
> can either perform cursive elongation on Arabic -or- not affect its
> letters at all but cannot put gaps between them.
> We could remove the feature to match web-platform-tests, but then
> how would we handle those cases?

I'm not sure. One could probably have some test.html like:

<link rel="match" href="possibility-1.html">
<link rel="alternate match" href="possibility-2.html">
<link rel="alternate match" href="possibility-3.html">

Then the test could still be described by the tuple (test.html,
possibility-1.html, ==) but also allow for the other possibilities. You
would have to have a rule that it wasn't allowed to mix multiple
rel=match with rel="alternate match" so:

<link rel="match" href="possibility-1.html">
<link rel="alternate match" href="possibility-2.html">
<link rel="match" href="ref2.html">

would be invalid (and fail during manifest generation). (I suppose
another option would be to allow this but depend on tree order here to
distinguish which alternates apply to which top level items).

The main advantage of this scheme is that it keeps the simple model
where (test, ref, type) form a unique id for a particular reftest.
Obviously the cost of this is that it's less convenient to write this
kind of test with multiple possible matches, and tests that have to
match N different things look like N different tests rather than 1 test.
However if these cases are rare that might be a tradeoff that's worth
Received on Tuesday, 19 August 2014 16:21:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:11 UTC