- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 30 Sep 2013 19:57:19 -0400
- To: www-style@w3.org
- Message-ID: <CADhPm3tmpBJ_F-FZbm4ij9xoZX_+qgZJ+CDkh6rfGbyR76KwhQ@mail.gmail.com>
Color Module
------------
- RESOLVED: Add ChrisL as co-editor on css4-color
- RESOLVED: Pull in SVG2 color section into CSS4 color
- RESOLVED: rgb() and rgba() will accent <number> rather than
<integer>
- RESOLVED: Allow <angle> in place of <number> for hues
- RESOLVED: Accept <percentage> as <alpha-value>
- RESOLVED: Accept rgba hex colors
- RESOLVED: No change to number of arguments to rgb/hsl
- RESOLVED: Add 'color-correction' property to Colors 4 draft, with
issue about the problem it's trying to solve and
consideration that it might not be the right solution.
=====FULL MINUTES BELOW======
Color Module
------------
tabatkins:
http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
<projector> http://tabatkins.github.io/specs/css-color/Overview.html
tabatkins: A few weeks ago we approved to take my new Color draft
tabatkins: This is a quick yay/nay on features we'll move to the ED
glazou: Chris might have input on this but he's not here yet.
tabatkins: I could use help defining what device-cmyk() means.
howcome: If you want CMYK to go into a PDF this is what you use.
simonsapin: Is this supported on screen?
howcome: No. The way people are using it this is just an addition.
bert: How do you know it's PDF output or not?
howcome: You just have two declarations. Browsers will ignore it.
tabatkins: I hope we could define it for screen.
* fantasai thinks we need ChrisL here
* glazou pinged ChrisL, he's arriving
tabatkins: When do we do this translation?
szilles: The normal meaning is that you don't transform it in any way;
you don't translate to the screen because it wasn't set up
for that.
tabatkins: So you can't interpolate this with other colors.
krit: Blending and filter used a unified RGB color space; How do you
translate to that color space?
tabatkins: In those cases I think we can just do a trivial transform;
there will be some loss but that cannot be avoided.
tabatkins: I think we should treat device-cmyk as a specific color
type that only interpolates with itself.
tabatkins: And if you use CMYK on a screen I'd like to still be able
to show it.
tabatkins: This will take care of blending and compositing.
szilles: PDF predates ICC; there were no profiles. I'm not convinced
adobe would advocate using device-cmyk since you're no
longer portable...
[back and forth, followed by drawing on whiteboard about resolving the
color of an overlay scenario]
[unminutable design discussion follows]
Hakon: You just dump all the colors into PDF, and the PDF readers
figure it out.
tabatkins: But we are a PDF reader. How do we composit this?
howcome: It's in the PDF spec .
<krit> PDF spec-
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf
TabAtkins: ... sending straight to printer.
howcome: Printer knows how to draw cmyk.
TabAtkins: But it doesn't know how to composit.
Scribe: fantasai
koji: ... compositing cmyk is different from rgb
TabAtkins: If you need a cmyk color for interpolating or compositing,
or whatever, calc closest rgb color, and use that.
dbaron: Then you are presuming non-device-specific cmyk.
TabAtkins: There's a simplistic one we can use, yes.
howcome mumbles
<dbaron> So if we have a formula for non-device-specific cmyk, why
would we not want to use that?
howcome: Sometimes you do want two different colors.
Florian: That's what media queries are for.
[Discussion of device-cmyk taking an optional fifth param, which is a
fallback rgb color]
howcome: I prefer browsers don't recognize device-cmky()
plinss: We want to be able to load into browser and print and get the
right color.
TabAtkins: All of our color math is specified in rgb space.
Florian: We need author of doc to not mix colors.
TabAtkins: Or to give us a profile, so we can translate properly.
[Something about not knowing the actual color until it's sent to the
printer]
Florian: 5th fallback param seems way to go for me.
TabAtkins: Want to make sure that, from implementer perspective, use
cmyk for doc but when compositing use rgb.
plinss: Wanting to use fallback color from cmyk() on pixel by pixel
basis, when compositing
[Florian/Tab note that you have to do this when compositing images
anyway]
SteveZ: There are rules in PDF for device-cmyk to rgb and vice versa
SteveZ: One suggestion is that you convert device-cmyk to device-rgb,
and then treat it as if it were sRGBA.
SteveZ: That's a fairly simple thing.
SteveZ: Won't give you "right" answer, but it's well-defined, and
solves all the problems, without having to do fallback or
something like that.
SteveZ: Should highlight what's happening.
fantasai: Let me see if I understand what you're talking about
fantasai: So you, Tabatkins, were saying that ....
fantasai: If you have a document where everything is opaque, some
things in cmyk and some in rgb
fantasai: No problem with sending to printer.
TabAtkins: Right.
fantasai: So you send to printer cmyk colors and rgb colors.
TabAtkins: Yes.
fantasai: If you have compositing, you do what?
TabAtkins: For pixels that are being composited, if any of the
arguments are cmyk, turn them into rgb fallback.
SteveZ: My suggestion was to use the PDF rules to turn cmyk to rgb.
plinss: Say you have one element, device-cmyk, another element on top
of it, partly covered and using rgb
plinss: Don't want the clear parts of the element to be using a
different color than the parts of the element that are over
the cmyk element
plinss: ...
plinss: If you have 1% opacity, don't want to jump into new color
space.
plinss: If you have one element next to other element, vs. just barely
overlapping, you also don't want slightly different colors.
[plinss discusses discontinuities]
florian: Being ugly at this point isn't that important; the author
messed up. If they don't want it to be ugly, specify colors
right.
plinss: Just don't want [discontinuities mentioned above]
fantasai: Can you just taint the entire doc if using device-cmyk?
TabAtkins: Would also have to taint it if there is any use of opacity
or compositing...
TabAtkins: Anything other than entirely opaque.
florian: PDF printing already has a pre-print checker, so maybe it's
ok
<SteveZ> In
http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
<SteveZ> Section 10.3 describes the rules for converting among device
color spaces
dbaron: This doesn't feel like a feature we want in browsers
dbaron: I feel like we should specify it in a way that the print
processors can have it.
dbaron: In some restricted set of cases.
dbaron: Do Antenna House implement things like opacity and blending?
howcome: I don't know.
howcome: I believe they support opacity.
howcome: Print processors, it's easy, they just toss to PDF.
howcome: They always print to PDF.
TabAtkins: Chrome *is* a PDF viewer.
fantasai: Then go to what PDF spec says
koji: Says that if PDF file has device-cmyk() then it must have
mapping, so that you can do interpolation.
TabAtkins: Could we do that? Assume some default ICC profile, possibly
implementation-defined, possibly by inspecting device, but
also have a way of specifying specific profile.
SteveZ: I would like to go ask color guys at Adobe.
* sgalineau seems we used the entire Color module time on
device-cmyk(); should we spend some time deciding which
new features move to the new ED?
fantasai: So plan should be, copy cmyk text from gcpm, add an issue
explaining the problem.
ChrisL: Sorry to be late, but you're all wrong.
ChrisL: If it's in device-cmkyk and you want rgb, you do classic ?
with absolutely zero indication that it will be what you want.
SteveZ: ...
TabAtkins: So we assume a probably UA-dependent translation rule,
TabAtkins: provide way to give an explicit mapping,
TabAtkins: and then treat device-cmyk as plain color for all purposes,
because we have a mapping.
TabAtkins: Default translation should be specified.
SteveZ: It's a page and a half in the PDF spec. Just point to it.
dbaron: Want to go back that we don't want this in browsers.
SteveZ: Why not?
SimonSapin: 2 issues, first one is whether it's supported at all in
browsers or more generally, on screen
SimonSapin: 2nd issue is, when we are printing, how does cmyk interact
with rgb when we do interpolation, gradients, compositing,
etc.
ChrisL: Depends on whether device-cmyk or ICC-profile standard cmyk.
ChrisL: If you have an ICC profile you know how to convert it to the
profile connection space.
ChrisL: The profile connection space is either CIE XYZ or CIE Lab
ChrisL: Both of these have property that there's no damage,
effectively.
TabAtkins: They have no gamma, so can put any other space into it.
ChrisL: Having done that, you then have to transform it down to sRGB
just to do interpolation, because that's the only color space
you have.
ChrisL: SVG2 had ability to specify interpolation color space.
ChrisL: So if you had gradient with stops in [lists various profiles],
no problem, do your interpolation in the profile connection
space, then spit out the result into the output color space
SimonSapin: What you just explained is all with ICC profiles.
SimonSapin: But the feature in GCPM is device-cmyk()
ChrisL: Means we can come up with a fallback rendering on screen.
ChrisL: Could use this in print.
Florian: That's the issue here.
Florian: This is what we were discussing before ChrisL arrived
Florian: When it's about gradients or animations/transitions, you can
decide not to interpolate. But for compositing doesn't have
an option. Can't return an error, have to draw something.
ChrisL: As side effect of all that, use exact same method for [...?]
ChrisL: Don't have to say, oh, this is RGBY, what do I do with that.
ChrisL: So, should we discuss...
ChrisL: SVG2 has a chapter on this.
ChrisL: Would much rather see this in CSS rather than SVG
ChrisL: Previously, dbaron was concerned that this was a lot of syntax
for helping photographers
dbaron: What's "this"?
ChrisL: All of the color chapter in SVG2
dbaron: Don't remember exactly what was in there. Some of it was about
prioritization
[we were trying to ship css3-color]
ChrisL: would prefer to put this in CSS4 color, and have the
discussion there.
ChrisL: Don't want to put things in there and then ... ?
ChrisL: As long as doesn't get screwed up, fine.
howcome: Works perfectly right now.
krit: Current implementations in browser it doesn't make sense to
differ between SVG colors vs. CSS colors because unified there
anyway.
dbaron: I agree that it makes more sense in CSS.
TabAtkins: OK, resolution, do we want to try for the full gamut of
colors right now? Or say that we do simple thing for
device-cmyk and just make sure we're compatible with full
extent
<dbaron> https://svgwg.org/svg2-draft/color.html
ChrisL: People who want CMYK will ignore that it's
device-specific-cmyk, and forget that they don't get what they
really wanted.
ChrisL: We should give people what they really want.
ChrisL: They can use common conversion softwares.
RESOLVED: Add ChrisL as co-editor on css4-color
RESOLVED: Pull in SVG2 color section into CSS4 color
[15 Minute Break]
TabAtkins: We're going to go through changes I've introduced in
css4-color, give a short description of each, then want
show of hands for "yes or no", whether want it in the
draft.
TabAtkins: Want to get a feel for what-all we should do at this level.
TabAtkins: I will an do arbitrary order.
Issue: #4 - hex with alpha
<leif>
http://tabatkins.github.io/specs/css-color/Overview.html#changes-from-3
TabAtkins: Right now to add alpha you have to convert to rgb()
dbaron: I'm a little iffy about the first four, though more the others
than this one,
dbaron: Because once you add multiple syntactic ways of doing the same
thing, when previously only some of them worked,
dbaron: laying a transitional period trap for authors.
dbaron: Things will work in the browsers they develop in, but not
others,
dbaron: When it could have been backwards-compatible.
ChrisL: I see your point, but don't think it'll be too long of a
transitional period.
Florian: But what about e.g. iphone 3S.
dbaron: I'm ok with them, but hesitant for that reason.
SteveZ: Other problem is serializing.
TabAtkins: That's a general problem.
dbaron: I think in general we should serialize to the most
broadly-compatible syntax
ChrisL: Disagree, because number has finer granularity.
TabAtkins: But you can convert to percentage, which has that
granularity.
ChrisL: Does that mean that if you provide hsl using angle units, and
then serialize it, you'll get back something that was some
other syntax?
TabAtkins: Yes.
TabAtkins: Should be defined already, or we need to define it.
TabAtkins: In order of these things, the only ones I feel strongly
about is
TabAtkins: #4 because it's a common request (hex colors)
TabAtkins: And #1 because of script-based color manipulation. Forget
to round, get weird results -- fails to parse sometimes,
sometimes not.
TabAtkins: Other two are less important, I just like them for
consistency.
TabAtkins: But if compatibility period pain is sufficiently large vs
benefit, I'm ok with leaving those out.
TabAtkins: On that note, can we get some votes?
#1 - number inside rgb/rgba functions
[Most raised hands for yes, none for no]
RESOLVED: rgb() and rgba() will accent <number> rather than <integer>
#2 - hgs() and hgsla() now accept <ang.le> in place of <number> for
hues
[most raised hands for yes, none for no]
RESOLVED: Allow <angle> in place of <number> for hues
#3 - All uses of <alpha-value> now accept <percentage> as well as
<number>
RESOLVED: Accept <percentage> as <alpha-value>
#4- rgba hex colors
RESOLVED: Accept rgba hex colors
zcorpan asks about compat impact
TabAtkins: Did compat research 3 years ago, compat issues are with
HTML, not in CSS
zcorpan: If it's been researched and conclusion is that it's safe,
then I'm fine
<dbaron> It looks like there was about half a no for #4.
<glazou> That half a no is mine.
TabAtkins: Another one .. allowing rgb/hsl to take optional 4th
argument so don't have to switch to rgba/hsla
#6 - give rgb/hsl ability to take 4th argument
ChrisL: We wanted the function name to represent the arguments
4-ish yes
5-ish no
TabAtkins: Ok, I'll leave it out
RESOLVED: No change to number of arguments to rgb/hsl
Discussing now, at #5 'color-correction' property
ChrisL: I hate it.
ChrisL: This was somewhat more relevant when Apple had slightly
different gamma than everyone else
ChrisL: If you known what the color means, throwing it at the screen
is reasonable to do if your device has smaller gamut than
sRGB.
ChrisL: Once Apple changed to match everyone else, less of a problem.
ChrisL: But if you have an AdobeRGB monitor you get really garish
colors if the browser just throws sRGB at the screen
dbaron: Are browsers currently displaying colors correctly?
ChrisL: Yes, as long as ... ICC profiles
dbaron: You're saying we do it right for images. Do the CSS colors
match the images?
ChrisL: No.
dbaron: Right, and that's the problem this was designed to give a
migration path for.
ChrisL: It's the wrong way to solve the compatibility issue.
TabAtkins: This only applies to untagged images. If you have a color
space specified, then you use that.
TabAtkins: It's only untagged images and CSS colors, because they're
essentially untagged.
ChrisL: CSS colors do have a profile, you just don't have to specify
it.
dbaron: They're supposed to be sRGB, but not how it has been
implemented correctly.
dbaron: ... plugins...
dbaron: But that's improved more recently.
ChrisL: Yes, e.g. flash is color-managed now.
dbaron: How do we get flash and css and images to match across devices
with different color profiles?
dbaron: The problem is that a lot of web pages expect colors to match
flash.
dbaron: But if we make CSS colors sRGB, and flash is not, then you get
lines in pages where should be seamless
ChrisL: ...
dbaron: I agree with your desired end state, but don't understand how
to get there from here, without users being mad at their
browsers.
ChrisL: They're getting what they want without that property, so how
is adding it going to change it?
dbaron: They're not getting consistent color across devices.
dbaron: This lets authors at least opt-in to saying they want the
correct behavior.
ChrisL: ...
dbaron: The behavior you're talking about, that CSS is color-managed,
is not reality right now.
TabAtkins: Spec says colors are in sRGB, but in practice they're not.
TabAtkins: Things match because they're handled the same.
TabAtkins: This property codifies that default is not color managed.
TabAtkins: But allows people to opt into the spec behavior.
dbaron: I would like to change default behavior eventually, but need
to solve plugin problem.
dbaron: Want API for browser (not content) to tell flash how to
color-manage.
ChrisL: You're saying that colors match seamlessly already.
ChrisL: An author can tell Flash to treat colors as sRGB to match sRGB
of CSS.
dbaron: If someone has the resources to take on adding something to
NPAPI, so we can tell plugins to do that, that would be great.
dbaron: But barring that, this is an alternative solution.
ChrisL: Doesn't seem that hard.
Jet: Not going to happen. People at Adobe that could do this have
other things to do.
Jet: 2 people who can do it that I know, don't work on that anymore.
SteveZ: My estimate was that it would be difficult because it takes
both sides to make the change: browsers have to ask, and flash
has to respond.
TabAtkins: At least on our side, it's both sides, because we have our
own implementation of flash in Chrome.
SteveZ: At least with Google, relationship has been pretty good, but
that's only one of the players that has to do it.
SteveZ: One comment is that, basically, area of plugins is sensitive,
and people don't like playing in that area for various and
sundry reasons, more political than technical perhaps.
SteveZ: My initial gut feeling is agreeing with Jet, sounds like a
good technical solution, but suspect the gods are not in favor
of it.
* glazou we should move on
ChrisL: We might do better if we ask
SteveZ: If all of the browser vendors asked for it, that would
significantly increase the chances of it happening.
* glazou we need to move on to charter renewal discussion
TabAtkins: Kills the coordination issue
TabAtkins: So, to wrap up. Yay or nay for having it in the draft? Can
always cut out later and then add the appropriately scary
issues around it.
SteveZ: I'm ok to put in draft, but issue should describe the problem
and say that this is *a* possible solution, but there may be
others.
dbaron: When you copied my text, did you copy the introduction bits?
Because that did try to explain the problem.
krit: Is this mainly for flash, or other content that could benefit?
TabAtkins: In other words, is this mostly a browsers vs. Flash issue?
krit: So, do we really want to add a property that will be deprecated
in 2-3 years?
dbaron: I don't know
TabAtkins: Ok, so big issue about this.
RESOLVED: Add 'color-correction' property to Colors 4 draft, with
issue about the problem it's trying to solve and
consideration that it might not be the right solution.
Bert: I'm not ok with putting in this property.
Bert: The property just says "do what I mean", and shouldn't have to
do that.
Bert: The problem is in the implementations.
Florian: Property says which of things I could mean I mean.
Liam is also not pleased.
Liam: Lots of changes here in OS support, too
Bert wants the issue to be very conspicuous
Received on Monday, 30 September 2013 23:57:47 UTC