- From: Robin Berjon <robin@w3.org>
- Date: Mon, 23 Sep 2013 12:31:17 +0200
- To: James Graham <james@hoppipolla.co.uk>
- CC: public-test-infra@w3.org
On 23/09/2013 11:48 , James Graham wrote: > Therefore I conclude that we should take option 1); simply consider > "should" level conditions in the spec as untestable (for us) as other > implementation-specific requirements on UI. If you really want to call > out these somehow, I would be happy for people to write should.txt files > describing all the should level conditions to guide people writing > implementation-specific tests. I would opt for a "modified (1)". By default, don't test SHOULD (they normally aren't testable) but allow people to use their better judgement and include tests for SHOULD in cases where they feel the specification was exceedingly cautious. The issue of devices not being able to support some functionality is orthogonal, and should really not be handled by use of SHOULD in specifications. For instance, an eInk device won't render colour, but it would not IMHO be a good use of anyone's time to put all mention of colour behind SHOULD in any CSS module that relates to it. For such cases test results are meaningless (beyond API exposure and the such) and ought to just be marked as such in the runner. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 23 September 2013 10:31:30 UTC