W3C home > Mailing lists > Public > public-css-testsuite@w3.org > March 2015

Re: [css3-ui] cursor image format tests

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 24 Mar 2015 20:04:09 -0400
To: Chris Lilley <chris@w3.org>
Cc: Public CSS Test suite mailing list <public-css-testsuite@w3.org>
Message-ID: <d0de93b76cec903802799ade2bc7dc5d@gtalbot.org>
Le 2015-03-24 08:05, Chris Lilley a écrit :
> Hello Gérard,
> Monday, March 23, 2015, 8:43:23 PM, you wrote:

>> Chris,
>> 1-
>> We want tests to be using simple language, simple vocabulary so that
>> ordinary people (your mother, my neighbour, children, grandparents who
>> never had a personal computer) could take the tests and enter results.
> Balanced against that, we also want the reported results to be
> accurate and for it to be crystal clear exactly what the test is
> testing.

The technical vocabulary (eg "Invalid PNG image, missing IDAT chunk.": 
that kind of text) should be in the text assert, in /* comments */ and 
<!-- comments --> and in the the <title> text.

The technical vocabulary does not need to be viewed by people taking the 
tests. A very wide majority of CSS tests are just visual tests, layout 
tests and do not (and should not) require any computer or web knowledge.

Reviewing tests, verifying correctness of tests is a different story.

>> So, words/expressions like "cursor" (some people think that a cursor 
>> is
>> the blinking white underscore-looking thing in black background text
>> environment ... which is also true!),
> Adding a tutorial on what a cursor is seems outside the scope of a
> test suite. I'm testing cursors. If the person running the test does
> not know what a cursor is, we don't want their results.
>>  PNG, "css-supplied hotspot",
>> "absolute URL", etc... should not be seen by people taking tests. But
>> they should be in the text assert and/or in comments in the test or in
>> <title> text.
> I'm fine to put that detail into the assertions.
> I'm not fine to allow test submissions by people who don't know what a
> computer is, or what a rectangle is, etc.

is a green rectangle.

And this
is a green box.

While this
is a green bar.

Confused now?

Green: you'd be surprised here to know that lime color is green for some 
people and not green (but rather bright green or light green) for 
others. It depends on how strict or lenient people taking tests may be 
and it can depend on psychological contexts too.

I've seen tests saying "square" but it was in fact and in reality a 
rectangle they should have written.

>> 2-
>> pale green: there is no reason to have a background-color here
> Its spring grass for the sheep. More seriously, a cursor which is
> mostly white with some black and pink is much more visible against a
> coloured background.

Correct. If you need to maximize background versus color contrast, then 
using a background color is welcomed and good.

> You will also see that mostly I used a mid grey, but changed that 9to
> peach) for tests with grey or grey+alpha cursors so that it was easier
> to see the correct result.

Yes I saw those mid grey cursors. I was thinking about those tests when 
I replied to Florian about this. Overall, a wide majority of tests 
submitted (not just yours or your cursor tests) do not need a colored 
background though.

>> 3-
>> width set to 8em: why not just let it be 'auto'?
> The intent was to ensure that the largest cursor plus largest
> reference image would fit into the box, while also making sure the box
> is fairly small; the cursor can then be compared more easily inside
> and outside the target area. I agree though that the value should be
> changed; as we don't set a font size and the cursors are sized in
> pixels, the width and height of the test area should be in px.

Huh... I'm not sure I understand what you're saying here (with regards 
to font-size and pixels) and why.

You may be referring to tests where there is a reference image in a 
small rectangle. It was also possible to include the reference image in 
the pass-fail conditions sentence..

>> 4-
>> why not just a black border instead of #555?
> I don't see how a black border makes the test any better.

Ideally, tests should be reduced, minimized as much as possible and 
focusing on 1 targeted area or 1 targeted feature or 1 targeted spec 
statement... unless a test is a compound test. Anything else - which is 
not part of the test - is extraneous or unneeded and should be using, 
resorting to default, initial values suffice.


Ideally, you want a short and clear pass-fail conditions sentence: the 
shorter, the better. Less reading; less thinking.

1 example:


<p>Test passes if, when moved inside the rectangle, the cursor becomes 
an animated butterfly and is not a butterfly when outside.</p>

I believe that sentence (slightly modified by me) would be sufficient. 
(If the butterfly is indeed blue and animated, then I believe that test 
does not require a background-color-ed area)

You add "coloured" and a background-color and this text:

If inside the rectangle the cursor does not change, or looks like a help 
cursor, the test fails.
Cursor by Vlasta, used here under a CC-BY license.


By the way, flag tokens are preferred in alphabetical order.

<meta name="flags" content="interact image animated">

<meta name="flags" content="animated image interact">

albeit alphabetical order preference has not been included in the new 
version of documentation.

>> Here's a test that couldn't make it before RC6 in 2011 and that I 
>> forgot
>> to submit:
>> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/cursor-025.html
>> You could create different "PASS" cursors (same look, same colors) in
>> different formats; that way, people would even be able to anticipate
>> expected results in a serie of tests.
> Nice PASS cursor. Your test area is too large, though. Getting back to
> your initial points, it also requires people to understand "hover" and
> "pointing device".

In the past, when I talked to friends on the phone, they wouldn't know 
what "cursor" was; they referred to it by saying "mouse arrow" or "white 
mouse arrow". "hover" was understood though.

> And the pointing device (trackpad, mouse, etc) does
> not change - the cursor changes.

Yes, you are correct on this: pointing device does not change - the 
cursor does. My mistake.

I will update that test; I will include a reference image in the 
pass-fail conditions sentence: this will reduce to minimum reading, 
words of sentence to read.

> So I think my wording on the test
> pass criteria is better than yours, there.

>> The kind of tests - ideally - you want to create as a test author are
>> tests where people do not have to think.


>> 6- The fallback cursor should be 'auto' and not 'help' in those cursor
>> tests.
> Because ....
> Help is better because it is not the default value. So it is easier to
> see if the fallback has been used, rather than some auto value. Making
> failure more evident makes for a better test.

The 'cursor: url' syntax requires a fallback value. So, like Florian 
said, any fallback would be good. The way I see this: the pass 
conditions of the test is the presence of described cursor: anything 
else should be assumed to be a fail and does not require to be 


>> 10- 006   ANI cursor: we already have cursor .ani test in CSS 2.1 test
>> suite.
>> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/cursor-024.htm
> Since that test does not have clear test assertions

Text assert is optional.

> or spec links,

That test has a spec link.

> mine is better for css3-ui..

Chris, overall, your tests are definitely acceptable and are interesting 
to have; I am just trying to suggest recommendations or improvements 

Test Format Guidelines

Test Style Guidelines

Test Templates

CSS Naming Guidelines

Test Review Checklist

CSS Metadata
Received on Wednesday, 25 March 2015 00:04:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:21 UTC