- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 19 Aug 2014 13:29:48 -0700
- 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:20 UTC