- From: Alan Gresley <alan@css-class.com>
- Date: Wed, 13 Apr 2011 22:52:35 +1000
- To: Brian Manthos <brianman@microsoft.com>
- CC: www-style list <www-style@w3.org>
On 13/04/2011 6:26 PM, Brian Manthos wrote:
> I must admit I'm a bit baffled by what your first example has to do with gradients.
Nothing at all. I was referring to this portion of your message,
>> As with IE9 previews, feedback is welcome -- but please try to keep
>> it below ear-piercing levels. ;)
and ways to avoid it. Moving on.
> Moving on...
>
> For your second example, I thought test suite entries are only supposed to include conformant syntax.
Correct. BTW, it wasn't a test suite entry. It was an example that
showed a gradient that would be difficult for a pass or fail to be created.
> I see the following issues in your example:
> 1. The webkit syntax you've included (which I think is
> Chrome 11 and Safari friendly) isn't conformant with the
> current spec. Fortunately, Chrome 11 appears to be more
> in line with the W3C spec so switching to that works
>for Chrome but apparently not for Safari.
> 2. If prefixes are allowed in the test suite, should
>probably add -o- for Opera to your prefix flavors.
Yes. We do need prefixes at this moment in time and the correct syntax
as per spec.
> 3. I think you meant IE10 preview, not IE9 preview. ;)
Sorry. :-)
> 4. You assert that FF and IE have the same rendering here.
> In fact, they do not; the IE Preview isn't using
>premultiplied > for interpolation.
OK, I know about this.
> Nonetheless, that aside I believe FF likely has a similar rendering (I don't have FF on this machine).
Which is IE 10 preview and which is FF 4?
http://css-class.com/test/temp/gradient-ie10-ff4.png
FF is on the right and there is a slight difference and this may have
something to do with FF doing gradient interpolation in premultiplied space.
> Ok, enough with the nits.
>
>
> You asked how to make a test case out of it, which is a good question.
>
>
> For some in-house testing, I've found decomposing the gradients useful.
Can you explain what decomposing is please?
> To test size and shape (radial) and direction (linear),
>I force "hard transitions" between colors.
> background-image: linear-gradient(37deg, red, red 50%,
> blue 50%);
>
> Using this method is very helpful in validating whether
> or not the angle linear gradients are behaving as
> expected. With "more normal" (i.e. not hard transition)
> gradients, it's often harder to see the differences
>between browsers.
>
>
> To test color transition consistency, using opposite gradients is helpful:
This is what I was thinking. Instead of white (in my example), I would
have aqua (opposite of red for #RGB) to transparent layered over the
same gradient but with red to transparent.
> background-image: linear-gradient(37deg, rgba(254,0,0,0.5),
> rgba(254,0,0,0.5) 50%, rgba(0,0,254,0.5) 50%),
> linear-gradient(217deg, rgb(254,0,0), rgb(254,0,0) 50%,
>rgb(0,0,254) 50%);
>
> Ideally, this should produce a solid color but as you play
> with the size of the element (or apply transforms) the color
>sometimes starts to shift as rounding effects come in to play.
I agree somewhat but the opposite of #FF0000 rgb(255,0,0) is #00FFFF
rgb(0,255,255), I was thinking of three layers.
1. (255,0,0) to transparent.
2. (0,255,255) to transparent.
3. transparent to <color> that is a composite of rgb(0,255,255) layered
over rgb(255,0,0).
Producing a solid color. This would be more difficult with alpha but at
the same time alpha can be used for composition of layered colors. I
haven't tested since I didn't have a browser that did interpolation in
unpremultiplied space.
I will test your methods. One question, why rgb(254,0,0) instead of
rgb(255,0,0)? Is this to do with the midway point? I claim that the
midway point or halfway between 'white' and 'black' is rgb(127,127,127),
where Tab says rgb(127.5,127.5,127.5) [1] (rambling thread which I made
errors). My basis for my claim is true representation of sRGB colorspace
as a cube.
> To test fidelity / quality of gradient, keep it simple and wide:
> div {
> height: 10px;
> width: 1000px;
> background-image: linear-gradient(left, red, blue);
> }
Wouldn't something with multiples of 255px be better? Having non
multiples of 255px may be the cause of banding.
> I see a lot of color banding in Chrome in some of my test cases.
> Like noticeably lower quality rendering. That's somewhat
> concerning for a desktop browser, though totally makes sense
>for a phone browser. IMO, at least.
>
>
> Then there's testing how many stops you can fit in before the
> implementation cries "Uncle!" Also, how they deal with such
> scenarios is interesting as well. Do you just not render
> the gradient? Do you render an approximation (as many stops
> as you can fit given your underlying rendering technology)?
> Do you reject the syntax as parse time? Do you accept it
> and render a completely different, unexpected gradient?
Very good questions. I need time to properly answer them.
> Combining all of these together makes for really interesting
> test cases that are good for comparative purposes -- and fun
> -- but are often more difficult to translate easily into
>pass / fail test suite cases then the one-dimensional tests.
>
>
> -Brian
This make me more afraid. How do you test 2D or 3D? These all need to be
broken into components.
[1] http://lists.w3.org/Archives/Public/www-style/2011Feb/0074.html
--
Alan http://css-class.com/
Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Wednesday, 13 April 2011 12:53:10 UTC