- From: Florian Rivoal <florian@rivoal.net>
- Date: Mon, 15 Feb 2016 09:07:08 +0900
- To: Simon Fraser <smfr@me.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Dean Jackson <dino@apple.com>, Chris Lilley <chris@w3.org>, www-style list <www-style@w3.org>
- Message-Id: <1A8825BC-1681-41F4-917D-A5FE00AAC077@rivoal.net>
> On Feb 12, 2016, at 11:16, Simon Fraser <smfr@me.com> wrote: > >> >> On Feb 11, 2016, at 4:15 am, Florian Rivoal <florian@rivoal.net <mailto:florian@rivoal.net>> wrote: >> >>> >>> On Feb 11, 2016, at 11:59, Simon Fraser <smfr@me.com <mailto:smfr@me.com>> wrote: >>> >>> >>>> On Feb 11, 2016, at 11:40 AM, Tab Atkins Jr. <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> wrote: >>>> >>>> On Wed, Feb 3, 2016 at 1:51 AM, Dean Jackson <dino@apple.com <mailto:dino@apple.com>> wrote: >>>>>>> 2. We will add a new function for describing colors that accepts a >>>>>>> color-profile name and a variable number of arguments. e.g. >>>>>>> color("bt2020", 0.7, 0.3, 0.1). The name can be linked to a >>>>>>> @color-profile, but we will also have some predefined keywords for >>>>>>> the most common profiles. >>>>>> >>>>>> Yes, exactly. I was thinking of icc rather than color, which is >>>>>> shorter and more descriptive (these are icc profiles). >>>>> >>>>> That sounds fine by me. >>>> >>>> Yeah, I like icc() fine. >>> >>> I dislike this name. icc is short for "International Color Consortium”, and that doesn’t make sense as a function name to me. >>> >>> Is CSS going to spec the acceptable list of ICC profile names, or is this left undefined? >> >> I tend to prefer color() over icc() as well. As for where the profile names come from, should at least hardcode sRGB, and could hardcode a few more, but in general I expect that we would also have an @rule to declare color spaces. >> >> @colors "adobe-rgb" { >> profile: url("https://www.example.com/adobe.icc <https://www.example.com/adobe.icc>"); >> } > > I think we’re prefer to avoid referencing external resources for colors. What do you show before the resource is available? Transparent? That's a real issue, and we should find some way of dealing with the fall back, but I don't think we can have a solution that does not allow for external color profiles. Otherwise we're not going to be able to do color matching with images, or to have print specific color profiles Maybe specifiying in the at-rule what kind of color model we're defining can give us an idea (even if approximate) of what to do when the resource hasn't loaded. @colors "name" { profile: url() | from-image(); model: rgb | xyz | cmyk | ...; } Or maybe we can extend the color function to have an explicit fallback. Or maybe we can define that the color function defaults to currentColor, or do that in most contexts but default to the background color in other contexts. Or maybe all of the above. - Florian
Received on Monday, 15 February 2016 00:07:45 UTC