Re: [css4-color] Make the r/g/b components be <number> rather than <integer>?

On Fri, Jun 8, 2012 at 3:54 PM, L. David Baron <dbaron@dbaron.org> wrote:
> On Saturday 2012-06-09 00:42 +0200, Simon Sapin wrote:
>> Le 08/06/2012 22:20, Tab Atkins Jr. a écrit :
>> >Could we make the rgb components of rgb/a() be <number> rather than
>> ><integer> in level 4?
>>
>> I’m in favor; I don’t see a downside in allowing it.
>>
>>
>> >I suggest we cast the components to integers in the same way we did
>> >for Transitions - normal round, .5 goes toward positive infinity.
>>
>> I’m not sure what rounding this is. I understand that as "n + 0.5 is
>> rounded to n + 1" (with n an integer). What about n + 0.1 ? In the
>> current Transitions ED I read "The interpolation happens in real
>> number space and is converted to an integer using floor().", I think
>> so n+0.5 would be rounded to n, not n+1
>>
>> In any case, the spec should define how to round (in what
>> direction), but maybe not at which resolution. If an implementation
>> can support more than 8bits per color channel the spec’ed rounding
>> should not limit that.
>
> So I think any definition of rounding behavior should be general to
> colors, not specific to rgb(<integer>, <integer>, <integer>).  We
> already allow arbitrary precision colors with rgb(<percent>,
> <percent>, <percent>).
>
> I'd be inclined to say there might be advantages to not defining
> rounding behavior here.  The experience I've seen with color
> management on different platforms has been that they round
> differently, but being off by one color component doesn't sound all
> that serious.  Being able to benefit from hardware acceleration may
> outweigh being able to define every result exactly.

Given that this kind of rounding could happen at parse-time, I'm not
sure I understand how hw-accel comes into this.  By the time the
hardware sees the color, it's already been converted to a packed argb
format, right?

~TJ

Received on Friday, 8 June 2012 23:01:56 UTC