W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] Need document.available_fonts() call

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 11 May 2010 15:37:29 -0700
Message-ID: <AANLkTilelYMIJ37KR5sHKA_BQRR5LAnL-NZYDoldsyHK@mail.gmail.com>
On Tue, May 11, 2010 at 2:30 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/11/10 4:59 PM, Tab Atkins Jr. wrote:
>> On Tue, May 11, 2010 at 11:09 AM, Perry Smith<pedzsan at gmail.com> ?wrote:
>>> Well, my take is just the opposite. ?Portability should dictate only if
>>> the
>>> user wants portability. ?I don't believe we confine what colors can be
>>> picked based upon what is portable.
>> Actually... ?some machines can display colors with rgb values outside
>> of the [0,255] range. ?But CSS clamps you to that range because it's
>> portable.
> CSS clamps to [0,255]? ?Since when?
> http://www.w3.org/TR/css3-color/#rgb-color says:
> ?Values outside the device gamut should be clipped or mapped into
> ?the gamut when the gamut is known: the red, green, and blue values
> ?must be changed to fall within the range supported by the device.
> ?User agents may perform higher quality mapping of colors from one
> ?gamut to another. This specification does not define precise
> ?clipping behavior.
> ?...
> ?Other devices, such as printers, have different gamuts than sRGB;
> ?some colors outside the 0..255 sRGB range will be representable
> ?(inside the device gamut), while other colors inside the 0..255
> ?sRGB range will be outside the device gamut and will thus be mapped.
> There is then an example that says that on an sRGB device rgb(300,0,0) will
> be the same as rgb(255,0,0)... but on a non-sRGB device they may well not
> be.

This is why I should read more closely, dammit.

Received on Tuesday, 11 May 2010 15:37:29 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC