- 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