Re: [css-color] Doubts on how we handle device-cmyk() and similar things

On Thu, Aug 21, 2014 at 8:28 AM, Florian Rivoal <florian@rivoal.net> wrote:
> On Thu, 21 Aug 2014 16:28:42 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> I don't think we need to do anything about it
>> for now, though; we can always add an attribute for the color space
>> later, when we have declarative colorspace support.  Right?
>
>
> If we don't have the tag now, we have a forward compatibility problem. If we
> don't reserve the name of an attribute to put color space information in,
> and spec the various API that take colors to reject objects that have
> unknown values there, then implicitely, we spec the various APIs that take
> colors to accept such objects and ignore the information in the color space
> attribute. Later actually giving it a meaning would then be a breaking
> change.
>
> Take the following code snippet
>
> var c = RGBColor(0, 128, 255);
> c.profile = "AdobeRGB";
> document.body.style.backgroundColor = c;
>
> Making current browsers choke on it opens the possibility that future
> browsers could treat c as an adobe RGB color. Letting current browsers
> ignore the (unspecified) profile attribute and understand c as an sRGB color
> makes that impossible without compat issues. This is true regardless of the
> name and value type we end up picking for the color profile attribute.

I don't understand.  This seems to assume that people would, today,
set a .profile property on their color objects.  Why would they do
that?

If they don't do weird things (like setting random properties that end
up colliding with our future extensions), then I don't see any problem
here.  RGB/Hex/HSL/HWBColor all default to the sRGB colorspace.
CMYKColor will default to either the device colorspace or the sRGB
colorspace.  You'll be able to change these out.

~TJ

Received on Thursday, 21 August 2014 18:35:43 UTC