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: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Jun 2012 16:01:06 -0700
Message-ID: <CAAWBYDB1FgHsorYjNW1gQUYzGUZUrO=M_XuoHFxU5qmbsjrbSg@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: Simon Sapin <simon.sapin@kozea.fr>, www-style@w3.org
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?

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

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