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

At 15:54 -0700 6/8/12, L. David Baron 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 realize that this would require a change of bracketed subject 
prefix, but: perhaps there should be a defined rounding behavior for 
<integer>s in general, not just in colors.
    The definition could be as loose as "where an integer is required, 
non-integers should be rounded to the nearest integer" or as precise 
as exactly what happens at the .5.  At the very least, it should 
define rounding rather than flooring (I still have nightmares about 
the flooring-vs.-rounding behaviors in old browsers).
    Good idea?  Bad idea?

-- 
Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/

Received on Sunday, 10 June 2012 13:40:07 UTC