W3C home > Mailing lists > Public > www-style@w3.org > June 2012

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

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 8 Jun 2012 15:54:19 -0700
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: www-style@w3.org
Message-ID: <20120608225419.GA23399@crum.dbaron.org>
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.


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Friday, 8 June 2012 22:54:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC