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

On Sat, Jun 9, 2012 at 12:54 AM, 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.
>
>
I agree. If the hardware supports more than 8bpp or if there's color
management, it's better that floating point is preserved.

Rik