W3C home > Mailing lists > Public > www-style@w3.org > August 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 21 Aug 2014 13:17:28 -0700
Message-ID: <CAAWBYDCe1dsLow-CRzvwk1204iP-xHZd0UY9nJXrdEWDKNRrYQ@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-style list <www-style@w3.org>
On Thu, Aug 21, 2014 at 12:43 PM, Florian Rivoal <florian@rivoal.net> wrote:
> On Thu, 21 Aug 2014 20:34:56 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> 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?
>
> How about a future site (or library), knowing how the .profile property is
> supposed to work, setting it the correct way. Then you run the site on an
> old browser, and it silently does the wrong thing.

That happens regardless.  Before we introduce color profiles, anything
using a color object will assume it's in the sRGB colorspace.  Putting
a .profile attribute on it wont' do anything for the old browsers.
This is similar to CSS - if you try and pass a colorspace argument to
a color function, it'll be invalid.  Just like CSS, if you want to be
robust in both worlds, you need to provide an sRGB version as well.
(In CSS, you provide it unconditially and first; in JS you
feature-test and provide it only if the browser doesn't support
profiles).

(At least this fails gracefully - being in the wrong colorspace just
means your colors will be a bit off, but are still more-or-less
correct.)

~TJ
Received on Thursday, 21 August 2014 20:18:15 UTC

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