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

On Thu, Aug 21, 2014 at 8:28 AM, Florian Rivoal <> wrote:
> On Thu, 21 Aug 2014 16:28:42 +0200, Tab Atkins Jr. <>
> 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";
> = 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

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.


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