CSS color break-out -- 11 May 2016

<Florian> RRSAgent: make logs public

<scribe> ScribeNick: zcorpan

<ChrisL_> waiting for Godot

<ChrisL_> https://drafts.csswg.org/css-color/#lab-colors

color

ChrisL_: we've had discussion in the last f2f for thing swe've wanted to do
... apple have fancy screens now and want to take advantage of that
... something something colorspaces
... XYZ is a colorspace that can describe all known colors
... XYZ fails to do white adaptation
... LAB sticks an axis to teh white point and if you take a perfect white surface, that's 100
... then two orthorgonal channels A and B that correspond to greenish and yellowish axises
... LAB is useful, you get it in physical measurement devices etc

Florian: in the luminosity direction, how white is 100%?

ChrisL_: there are different standards for standard daylight and the one sRGB uses

<dbaron> ... uses D65

<dbaron> (6500K)

ChrisL_: if you look in the spec, i've tried to keep the math to a minimum

<dbaron> ChrisL_: (before) LAB uses D50

<dbaron> ChrisL_: ... this is all just summarizing the spec

ChrisL_: issue about out of range numbers
... steps for how to convert ...

TabAtkins: what is a reasonable range for C?

ChrisL_: to go from LAB to ???

<dbaron> ACTION ChrisL_ to add note explaining a reasonable range for C in lch() to the spec

<trackbot> Sorry, but no Tracker is associated with this channel.

<dbaron> TabAtkins: so conversion between a/b and c/h is just rectangular to polar

ChrisL_: this is using the color() function, see example 9
... it's like @font-face
... you give it a url

<TabAtkins> https://drafts.csswg.org/css-color/#color-function

TabAtkins: idents is the right thing

ChrisL_: ident and then as many numbers as needed

<dholbert> (inside of https://drafts.csswg.org/css-color/#icc-colors )

Florian: why only 2?

ChrisL_: sRGB could be added but it doesn't give us anything new
... happy to add it if people want it

smfr: makes sense for consistency

ChrisL_: there's a section about grayscale
... consider replacing the grayscale section with a grayscale colorspace
... we had a briefer syntax

leaverou: what about thing like named color profiles ?
... spot colors

ChrisL_: does not allow overrange values
... we've handwaved about this for a long time
... there was a linear space that was easy
... there's something black that's not absolute black
... that lasted for 2 years and then they decided to use a wider gamut if you want a wider gamut
... we should have early clipping

dholbert: it's quiet about that

<dholbert> s/dholbert/cabanier/ (wasn't paying attention, sorry)

<dholbert> (maybe that was rik?)

smfr: do we want commas?

TabAtkins: no, because we want to allow alpha
... need to distinguish

ChrisL_: so no commas between numbers in examples

<dbaron> ACTION ChrisL_ remove commas between in the color() examples

<trackbot> Sorry, but no Tracker is associated with this channel.

ChrisL_: next section is P3 and Rec 2020
... these refs can be added to MQ4

<dbaron> ACTION ChrisL_ fix the currently-broken Rec.2020 reference in the spec

<trackbot> Sorry, but no Tracker is associated with this channel.

leaverou: if one is supplied no color profile, it will be ignored?

ChrisK_: @color-profile foo icc profile which is treated differently

leaverou: this might be confusing in some cases

ChrisL_: it will look wrong if you copy a color but not the profile

TabAtkins: Rec.2020 is not a valid ident
... Rec2020 works fine

ChrisL_: ty noted

TabAtkins: also ascii lowercase pls

ChrisL_: mkay

TabAtkins: match what MQ does

<dbaron> ACTION ChrisL_ fix Rec.2020 and Rec2020 to be rec2020, and DCI-P3 P3 to either (consistently) dci-p3 or p3

<trackbot> Sorry, but no Tracker is associated with this channel.

ChrisL_: colors in wide color space and teh device with a narrower space
... what do you do with the ones outside
... if it's an image with a nice gradient, things can look ugly
... you move everything proportionally so that it looks nice
... it's handwaving
... maintain the relationship between colors but they're all going to match
... it's fine for a photograph but not when you want to match up a color in an image with a css color
... saturated is useless

TabAtkins: can we drop it?
... can we only allow them to choose the ones we care about?

ChrisL_: yeah... think so

smfr: i don't know if we want to drop absolute color metric, might be useful for testing

ChrisL_: "this has to have an absolute luminance of this"

Florian: if you have several profiles with the same color space?

ChrisL_: last one wins

TabAtkins: they cascade as a unit

cabanier: this is basically unused. can we leave it as is?

ChrisL_: in svg2 you have to overwride the profile
... should we remove the rendering intent thing?

cabanier: just use the default

TabAtkins: need some way to choose the default

ChrisL_: perceptual is less good for css

smfr: why is rendering intent tied to color profile?
... you want to specify rendering intent ...

ChrisL_: the way ICC profiles work, is you have a profile for your source data
... then you have a profile for your output device
... compose those two
... how are you going to handle out of gamut colors
... if you select perceptual ...
... it's less applicable to a wide gamut screen
... an image has an intent built in
... you can't override it

TabAtkins: if the profile has multiple intents you can specify the one you want

Florian: if the profile has multiple, does it specify hte default?

ChrisL_: yeah

cabanier: we set that as the default in the product

Florian: it's ok for photos and what we should use for the rest?

ChrisL_: yes
... named color profiles, instead of having a mapping from a number
... you have mapping from a name
... people can do their own ones
... this syntax does not cope with that but can be extended to do so

Florian: color() function, either a list of numbers or a string
... the other extension is to allow you to name your colors
... new descriptor, @color-profile foo { src:...; named-color: "myblue" 00255, ...;
... maybe not necessary because of variables

leaverou: can you rename existing colors?

ChrisL_: yes

TabAtkins: don't object but it's strictly not necessary

ChrisL_: i like it but variables is enough

cabanier: print wiht specific ink...

Florian: can do that with this or with variables
... the variable contains "foo" 00255 so it contains the righ tcolorspace

TabAtkins: are these profiles text files?

ChrisL_: no terrible binary files
... tool to convert to xml so you can hack and convert back

dbaron: some security vulnerabilities

esprehn: apple have fixed security bugs in icc

ChrisL_: should restrict to same-origin

TabAtkins: web policy, things should default to same-origin

ChrisL_: why are people using google fonts

TabAtkins: CORS, no problem

smfr: before you download you have to wait for ICC to download, like with fonts
... need to describe what should happen before it is downloaded
... would not impl except for built-in color profiles

esprehn: same for us

Florian: context-dependent profile

esprehn: won't impl

Florian: what do you fallback to?

esprehn: wouldn't paint, same as fonts

Florian: so everything's white?

esprehn: yeah

<dbaron> ChrisL_ (above): flash of uncalibrated color

esprehn: i'd like to see that you can specify a name so you don't need to download if you already have it

ChrisL_: fonts have local() for that
... fine to have that here also
... how do you name your profiles, typically don't have a unique name
... how do i define it?

TabAtkins: platforms can define what their names are and you can put it in the spec?

ChrisL_: so it's different per platform? -_-

TabAtkins: here's url, here's hash

esprehn: not a security issue, privacy issue

TabAtkins: fingerprinting is a lost cause

dbaron: you can binary test for any font

TabAtkins: fingerprinting is not fixable

leaverou: if i'm using super-RGB color space, makes sense to fallback to sRGB until it's loaded

TabAtkins: so fallback to a known name?

dbaron: is there a dictionary of downloadable profiles we can name?

TabAtkins: we can inline them in the spec, they're small

Florian: want to point to an image to use it's profile

ChrisL_: we can put an appendix of common profiles
... print profiles are not small

TabAtkins: in houdini we want these to be serializable
... represent something in the string OM
... here's the profile, it's 700 bytes of chars
... the color is considered invalid until the profile is downloaded

esprehn: not going to reparse

TabAtkins: hrm
... ok nm

ChrisL_: if you have a font stack, how does it work when the primary is downloaded

esprehn: recompute, not reparse

TabAtkins: fallback in color() fallback is like font list

esprehn: that's implementable

TabAtkins: must provide a fallback

ChrisL_: fine with that

leaverou: want to be able to fallback to a different profile

TabAtkins: that's fine
... in the color profile rule you can have a list of fallback profile names
... also in the color() function you can have a fallback color

cabanier: have to always specify fallback? no optional, ok

Florian: can you use rgba() in the flalback?

TabAtkins: ya

ChrisL_: open issue, blending happens in sRGB
... which will give you clipping problems
... also doing maths wrong
... was going to add linear
... there's hardware support
... you can get the right result with LAB
... we need a thing that says how you composit things

smfr: compositing and blending has a similar problem

cabanier: the gamut is being worked on in the canvas spec
... need to specify, just 1

smfr: we can't change the default because that breaks web pages

TabAtkins: subframes does it only work for top-most windows?
... iframe

Florian: if it doesn't say but the iframe does, does it propagate up?

TabAtkins: no. you can have two iframes

smfr: can't find linear blending in the spec

ChrisL: it's an open issue

Florian: when you've done your things in your colorspace, when you've done it, what do you export it into?

ChrisL: the output colorspace, whatever that is
... LAB is convenient for this reason

Florian: if you use anything but LAB do you need to go through LAB first?

ChrisL: yeah

Florian: when that's specified, do the color math other than oclor blending also happen in that colorspace?
... if we have LAB, can i switch to it and use it for ???

ChrisL: yes but you get different result

Florian: ya that's teh point

cabanier: if you render in colorspace then all colors are in the same colorspace

ChrisL: i've seen examples of interpolation of ???
... can we pick a placeholder name?

TabAtkins: document-interpolation-color-space

smfr: working color space?

TabAtkins: yeah

cabanier: you map your colors so it's fine

ChrisL: 3x3 matrix
... don't use 8 bits

ACTION ChrisL working color space

<trackbot> Sorry, but no Tracker is associated with this channel.

Florian: sRGB?

ChrisL: auto is sRGB
... linear-sRGB
... LAB
... any others?

cabanier: the list of working spaces can't include linear?

ChrisL: why not?

cabanier: can't implement it yet

ChrisL: that's wrong. HW has it already
... can do it in linear-sRGB with clipping

cabanier: need to change the blending spec
... so the output is bogus?

ChrisL: no, it's wrong now but people are used to it
... yes you will get a different result, if you're not using linear space you're technically get the wrong result now
... additivity...
... measure the light of two lights
... additivity means i can take the two numbers and get the right result
... in linear space you get the right result with +, otherwise not

Florian: in LAB, linear matches perception, which is nice

ChrisL: exactly

smfr: MQ?

cabanier: should match canvas
... ... p3 2020, optimal (matches the screen)
... on iMac you would be compositing in p3
... the gamut most closely matches the output

ChrisL: ok so MQ

Florian: i think what's in the spec now which is TabAtkins's interp. of what we had in the mailing list, is fine with me
... if people disagree say where and why

dbaron: this is a new type of MQ
... MQ where more than one of the values can be true

TabAtkins: yeah all the range based ones have that

dbaron: it's a set MQ rather than a discreet MQ
... might want to describe as a different type

TabAtkins: ok

ChrisL: are the ordered?

TabAtkins: only range features have an ordering

Florian: that you can do "less than"

dbaron: color gamut sRGB means it can do all of sRGB

TabAtkins: should we add a value for "narrow" for extra-low gamut (below sRGB)?

dbaron: concerned whether we CAN calculate it, if we have information to calculate it

Florian: should i load normal images, fancy images or super-fancy images

leaverou: percentages seems useful

smfr: no this is good enough

TabAtkins: boolean context are true for anything other than none or 0
... not (boolean) is true

smfr: you're asking about the OS, not the screen

TabAtkins: not talk about the output device, need to fix wording

Rossen: present to projector

Florian: two screens?

esprehn: every monitor has its own profile, if you move a window between two, we ???

<esprehn> we repaint the window, which resolves the colors again

Florian: the incentive for UAs to lie is not high, it only makes you download heavier images than you need

TabAtkins: if there are multiple screens

Florian: why not the highest?

TabAtkins: in general you want the lowest
... want to see the same thing as what's on the projector
... below CSS

Florian: there are objections that this is not restricted to RGB spaces or the screen media type
... if you have a whatever colorspace, if it's bigger then p3 then you match
... people have disagreed with that
... maybe add a cmyk

ChrisL: we have TVs which have ???

Florian: if you have a sucky printer sRGB is what you get

TabAtkins: we can add specific named variants

Florian: for UAs that don't output in cmyk, this has 0 impl cost

TabAtkins: we dismiss the objections and go with the current design

Florian: happy with that

ChrisL: publish this?

TabAtkins: intent to publish

PROPOSED RESOLUTION: publish css-color and mq4

dbaron: there's impl interest for some things but not others
... might be worth trying to figure that out sooner rather than later

TabAtkins: figure out what we want to impl

ChrisL: color-mod() problems TabAtkins?

TabAtkins: 1) syntax is confusing and crappy

<smfr> https://drafts.csswg.org/css-color/#modifying-colors

TabAtkins: i agree partially
... it's overcomplicated

esprehn: aliasing for everything? can we not do that?

TabAtkins: 2) ??? is not super useful for real-world stuff
... modifying one color ... suggested some different operations that i want to put in here instead
... replace this with something like blending two colors together

leaverou: lightness or mix with white and black which works better

TabAtkins: color blending, color contrast, tint and shade

leaverou: i impl a polyfill, it occurred to me that there were lots of (((()))) like lisp

TabAtkins: the grammar is intended to reduce that

leaverou: suggest keywords

TabAtkins: agree

leaverou: crazy idea, what if we can use calc(color + semi-transparent white) then it blends with alpha blending?

TabAtkins: calc is for numerical things
... we have cross-fade as existence proof that we use a new function for specific things
... we need color blending for convenience and so you can ???

Florian: device-cmyk

ChrisL: if you have calibrated device-cmyk

Florian: that's no problem

ChrisL: if you don't provide a fallback you get a bad color

Florian: how does it work?

ChrisL: it means here are some numbers, don't mess with them at all

Florian: if we composit and alpha-blend ...

ChrisL: if you use color() to do that, it looks better
... inks are not transparent, can't overlay them
... have a pattern of dots instead in a grid
... overlaid in different angles
... if you have a pale yellow and then few dots of black
... that's what device-cmyk is for
... don't want those black dots

Florian: why does output to PDF file have anything to do with the screen?

TabAtkins: don't have at a distance logic in MQ

Florian: if you're a headless device?
... OS doesn't know what to do
... what does the MQ do?

ChrisL: it should say yes to everything, can print to pdf in any profile

leaverou: can we get rid of device-cmyk somehow?

TabAtkins: it's implemented

Chris: black point compensation
... white is easy
... TVs can get much darker black

TabAtkins: can we not do something like white compensation?

Chris: no. the spec says why
... same mutual axis
... it's not pegged at 0 it's pegged at some dark
... certain amount at the bottom for deeper blacks
... do need to cope with that
... wording about rendering intents
... black point compensation matches or not
... with or without black compensation
... in PS it will ask if you want black compensation

TabAtkins: which do we want?

cabanier: turn it on

TabAtkins: ok. done?

cabanier: color conversion engine cna do it for you
... same thing happens with whites
... white stays white

RESOLUTION: do black point compensation

scribe: when converting from profile to another

smfr: for print also?

Chris: yeah
... doesn't affect p3, does affect 2020

TabAtkins: can i reformat everything?

Chris: sure

Florian: the only thing we haven't agreed on is the working color profile?

Chris: right

leaverou: device-cmyk
... stylesheet was used for printing to ebook
... using something similar to device-cmyk
... one problem is that you specify a device-cmyk color but you want ...
... it would be nice to specify which profile to use

TabAtkins: use the color() function and the cmyk profile?

leaverou: want to use device-cmyk for print

TabAtkins: what's wrong with just defining the cmyk profile in color() instead of device-cmyk?

leaverou: i thought we decided to keep device-cmyk?

TabAtkins: will fix by having a decent list of predefined profiles, one of those can be device-cmyk
... falling back to something you have defined

Chris: seems backwards

TabAtkins: if you have a correct profile for your output device...

dbaron: is the assumption is that only print uses device-cmyk?

leaverou: never want it for screen
... not just about PDF

dbaron: do you want a magic profile name for device-cmyk vs other

leaverou: want to specify colors once

Chris: want to see results from impl

Florian: the printer has everything it needs to do it right

TabAtkins: use color(cmyk) will be good

leaverou: ok that works

TabAtkins: get a good conversion instead of a naive

RESOLUTION: if you accurately describe the output device's color profile in an @color-profile rule then a sane impl will not fuck with your colors so this is sufficient as a replacement for device-cmyk in general and provides a good RGB fallback automatically

TabAtkins: we can deprecate device-cmyk

- DRAFT -

CSS color break-out

11 May 2016

Attendees

Contents

color

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output