W3C home > Mailing lists > Public > public-css-testsuite@w3.org > August 2014

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 19 Aug 2014 13:29:48 -0700
Message-ID: <53F3B3BC.3000809@inkedblade.net>
To: James Graham <james@hoppipolla.co.uk>, public-test-infra@w3.org
CC: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
On 08/19/2014 09:21 AM, James Graham wrote:
> 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">

This is an incorrect use of 'alternate'. Link rel keywords
form an independent list (with the exception of 'alternate
stylesheet', which was a mistake).

> 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
> making.

I... don't see why this is better. Also, as plinss and bz pointed
out, we use the multiple-references feature frequently as well.

~fantasai
Received on Tuesday, 19 August 2014 20:30:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:27 UTC