Re: [css3-ui] cursor image format tests

>> 1) Since you're testing for various image formats, I'll first note
>> we haven't yet added anything to the specification regarding
>> formats. (Rossen should get back to us this Wednesday, and we'll know more then).
> 
> Yes, I know. And this had previously hindered writing such tests.
> 
> The point of making the tests was to allow an informed, test-based decision as to
> what the spec should actually require in terms of image formats. I
> would then update the tests for those formats which are not mandatory.

If you're going down that path, testing various SVG modes would be quite good as well.
https://svgwg.org/specs/integration/#processing-modes
I believe that Chrome and Firefox support the secure static mode (which Tab and I were
proposing to make a MUST), while Safari supports the secure animated mode (which we
were proposing as a SHOULD).

>>> 009   PNG image with css-supplied hotspot, relative URL, no fallback.
> 
>> This test is incorrect. Per the spec's grammar, a fallback is
>> required. You should change the description of the test to: "The
>> test passes if, when moved inside the pale green rectangle, the
>> cursor does not change", include "invalid" in <meta name="flags"
>> content, and change the assertion to "Test checks that a fallback cursor is required."
> 
> My bad. I thought that fallback was optional (I think it used to be,
> for the cursor property).

It's been mandatory since the 1998 PR of CSS2.0, but it was optional in the 1998 WD (and in the 1997 WD, you could not have a fallback). So you're correct, but I am not sure whether to praise your memory, or to suggest you chose a slightly newer draft to work from when writing tests :)

>> "The default object size for cursor images is a UA-defined size
>> that should be based on the size of a typical cursor on the UA’s operating system.
> 
>> The concrete object size is determined using the default sizing
>> algorithm. If an operating system is incapable of rendering a cursor
>> above a given size, cursors larger than that size must be shrunk to
>> within the OS-supported size bounds, while maintaining the cursor image’s intrinsic ratio, if any."
> 
> Hmm, the default sizing algorithm is that wierd 150 x 300 px thing?
> Which is then shrunk down to "typical" cursor size?

No, that's not that one. It's this one, which is much less silly:

http://dev.w3.org/csswg/css-images-3/#default-sizing-algorithm

Relevant quote:

> [...]
> If the specified size has no constraints:
>  - If the object has an intrinsic height or width [...]
>  - Otherwise, its size is resolved as a contain constraint against the default object size. 



>> If a browser has deficient
>> support for some variants of PNG (or .cur, or whatever), it is
>> useful to know and to get it fixed, but do we want to hold it
>> against them in the context of the css3-ui spec?
> 
> As examples, Firefox correctly renders the PNG images when used on the
> HTML img element and when included with css :before content, but
> renders some of them incorrectly (double gamma correction or no gamma
> correction, depending on color type) when used as cursors.
> 
> I was previously unaware of this flaw and it would not be exposed by
> just testing image formats, only by testing image cursors as well. So
> for interop, clearly these tests have value. Once they are reviewed
> and show up in the CSS3 UI testsuite, I can raise a bug on Firefox,
> pointing to the ones that fail.

Fair enough. To be clear, I want the tests of the image formats *using cursor*
to exist, I was just not sure which was the right host for them. But if the WG
and the process are conformable having them in the css-ui test suite, I'm good
with that, as it does fulfill the criteria you mentioned.

I'll also note that cursors are somewhat special, and there may be platform
limitations as to what you can do. The spec mentions one about size, but I wouldn't
be surprised if there were some about color bit depth or gamma. That said, 
if there are such limitations, having tests will expose them, and then we can
add relevant wording to the spec to say how to deal with them.

 - Florian

Received on Tuesday, 24 March 2015 12:53:18 UTC