W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-color] . 12-Bit deep color support.

From: Simon Sapin <simon.sapin@exyr.org>
Date: Mon, 09 Dec 2013 13:43:52 +0000
Message-ID: <52A5C918.8090305@exyr.org>
To: Daniel Beckstein <daniel@beckstein-rehau.de>, www-style@w3.org
On 09/12/2013 09:04, Daniel Beckstein wrote:
> With upcoming 4K and OLED monitors, with 10 Bit support, it eventually
> would make sense to extend the web-colors to 12 Bit.
> Currently webcolors are defined *8 Bit *– ‘web’ *sRGB* (like: #FFFFFF or
> rgba(255,0,0,1) )
> So I propose adding something like *12-Bit* ‘extended-web’ *sRGB *where
> you define colors like:
>   * X#*FFF* FFF FFF - instead of #*FF* FF FF
>   * Xrgba(*255*16*,0,0,1) - instead of rgba(*255*,0,0,1)
> Supporting just 10 Bit (what is actually just needed by upcoming
> displays), would be quite difficult because of the poor 8+2 Bit format,
> so the color *white* would be X#8FF - instead of X#FFF or #FF
> Daniel Beckstein


Actually, CSS colors are not defined to be 8 bits. You can already use 
non-integer percentage (with any number of digits after the decimal 
point) in rgb() and rgba(). The exact rounding behavior and precision is 
left to the browser to decide.

rgb(0.1%, 0.1%, 0.1%) may or may not round to rgb(0%, 0%, 0%), depending 
on software and hardware support.

CSS Color Level 4 will also extend rgb() and rgba() to accept a 
<number>, where an <integer> was used, so that you can write:

rgb(0.25, 0.25, 0.25), which may or may not be rounded to rgb(0, 0, 0)

The range will still be 0 to 255 which only made sense in the 8 bits 
era, but the syntax will allow arbitrary precision.


The hexadecimal notation #rrggbb will forever be stuck to 8 bits of 
precision, but any syntax hack to change that is not worth is IMO, given 
the other notations.

Simon Sapin
Received on Monday, 9 December 2013 13:44:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC