W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Paris F2F 2013-09-13 Fri II: Color Module

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 19:57:19 -0400
Message-ID: <CADhPm3tmpBJ_F-FZbm4ij9xoZX_+qgZJ+CDkh6rfGbyR76KwhQ@mail.gmail.com>
To: www-style@w3.org
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
  - 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.


Color Module

   <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-

  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

  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

  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
  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
  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
  <SteveZ> In
  <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,
  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,
  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
  [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
  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

  <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
  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

  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
  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

  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
  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
  [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
  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
  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
  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
  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
  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

  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
  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

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