[CSSWG] Minutes Seattle F2F 2017-01-11 Part IV: CSS Color

=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS Color
---------

  - The issue of what happens to rgb() etc with Working Color Spaces
      will be moved to another day when ChrisL & dino are available.
  - RESOLVED: Add color computation section to color spec.
  - The resolution of currentColor for color property will change
      from used value time to computed value time.
  - Florian will test border-color:transparent to see if
      implementation is different from the spec.
  - RESOLVED: Add that if you transition to/from current color use
              numeric value
  - Before the Color spec can include a reference to DCI P3 Chris
      will need to investigate how to get it to comply to the W3C's
      normative reference policy.


===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/seattle-2017

Scribe: nainar

Summary of morning
==================

  [There was a brief summary of topics covered during the morning
      breakout. See parts I through III of 2017-01-11 minutes.]

CSS Color
=========

What happens to rgb() etc with Working Color Spaces?
----------------------------------------------------

  <nainar> https://github.com/w3c/csswg-drafts/issues/481
  dino: The rgb function defines srgb values
  dino: Change the core function like name/color ...
  <dino> we do blending in non-linear sRGB
  <dino> keeping the rgb() things in sRGB is going to be a pain for
         the user
  <dino> they'll have to convert everything
  <dino> If the working color space is only for blending, then I
         don't expect it to be useful. What's more important to
         blending is whether you do linear or not. Microsoft had
         some thoughts on this.
  <dino> Note that colors won't change on existing documents. This
         is only for documents that explicitly say "Hey, I want to
         use AdobeRGB"
  <dino> And I think there is a difference between the working color
         space and the way you do blending of transparent colors.
         For example, we technically don't do it right in sRGB at
         the moment (we = CSS)

  Florian: Color interpolation will be calculated according to color
           space.
  Florian: If you want to do outside of gamut you want to use color
           space.
  dino: You already have to address color outside the gamut.
  dino: Authoring tools set a working color space - anything in the
        space requires you to set all the colors.
  Florian: If you set color in p3 > sgb and your working space is
           srgb - you will have a problem.
  dino: Exactly what we have today.
  Florian: Everything collapses to srgb.
  dino: we draw them like ???
  dino: apple hardware - retina/iMac - displays that support more
        than srgb
  Florian: What you are doing is having the working color space be
           the output device color space.
  SteveZ: There is a fusion between what author see and
          implementation sees.
  SteveZ: dino is talking about color space sees.
  Florian: I am speaking of space in which you do color math.
  Florian: Putting two transparent colors over each other - that is
           the working color space.

  <smfr> https://drafts.csswg.org/css-color/#working-color-space
  smfr: Working color space - author of doc says I want color space
        to be p3 - then uses rgb color - the component is
        interpreted in working color space.
  Florian: What if you don't define it?
  smfr: It means that things specified in srgb will be rendered in
        srgb
  Florian: What if you have a semi transparent color over srgb?
           which space do you calculate in?
  smfr: We will use the display color space.
  Florian: In non linear - which is not specified outside srgb gamut.
  smfr: On mac we will use something ??? p3, on iOS we use unclipped
        sRGB - allowed to go below 0 and greater than 1.
  Florian: The working color space is the output in that case - and
           I want to preserve that - so that if you specify p3 -
           they continue to use srgb space.
  Florian: One reason I am thinking is consistency, and other reason
           is if you want to switch color space - it is prettier if
           you want to work in the math space, keeping legacy color
           notation as always in srgb is better to me.
  smfr: That's not how authoring tools work - you choose outside of
        srgb then you automatically want to use srgb space.
  smfr: We have asked adobe in the past about what they think
        authoring tools should use.
  Florian: Is this good authoring practice - don't get that from
           adobe input.
  Florian: If you mix stylesheets from origin - switching rules in
           one style sheet messes with the other stylesheet which is
           not nice.

  Florian: Can we really have this discussion without Chris Lilley?
  SteveZ: Legacy color was defined to be srgb - changing now will
          have unfortunate consequences - people don't expect that.
  SteveZ: If you could specify the color space - you wouldn't use
          unless you wanted srgb.
  Florian: Our current function doesn't have the s ahead of rgb().
  astearns: Come back when we have dino and Chris Lilley.

Computed and used values for <color> values
-------------------------------------------

  <nainar> https://github.com/w3c/csswg-drafts/pull/871
  Florian: Came out of parallel discussion - color values aren't
           used in color property only.
  Florian: We want these places to do computed/used values the same
           way.
  Florian: We have defined this for color property not color value
           type - caretColor asks that you do the same as color
           property with changes.
  Florian: Define in one place how color works - inherit/non inherit.
  Florian: Pull request has proposed definition.
  Florian: Current color boils to current color - at used value time
           - same as parent, case of everything else (other than
           color) - used value is same value as used value property.
  dbaron: Move from way it was done till now.
  dbaron: looking at old spec its clear.
  Florian: Is this way of trying to define the behavior the way to
           go? Seem sane to have section in css color space that
           defines computed and used value?
  dbaron: Reasonable to have section.

  RESOLVED: Add color computation section to color spec.

  Florian: At computed time color value becomes inherited for the
           color property.
  astearns: Section would say here is how color values work, and
            color property would refer to it except for exceptions.
  Florian: Hard to observe given that computedStyle gives you used
           value at serialization time.
  Florian: We use this for animation purposes, color value is a
           keyword but we still interpolate from number value.
  dbaron: Let's specify for color value, as better than current
          color walking up the tree to look up the color property.
  Florian: I'll take that feedback in - left undefined with issues
           serialization for all the new values will be.
  Florian: rgb/rgba/named colors/ hls? - documented the
           interoperable behavior.
  Florian: One thing where we don't have interop is when you
           serialize color that is transparent and has value other
           than 0 in rgb channels.
  Florian: Gecko serializes transparent as transparent the keyword.
  fremy: Difference between 0,0,0,1 and 0,0,0,0.
  Florian: They behave the same except for gradients - for
           transition we are fully interoperable - gradients safari
           disagrees.
  Florian: We want to be able to opt in to be different good thing
           is with serialization is different.
  dbaron: If you want 0,0,0,0 -> serialize as transparent
  Florian: No one serializes that as transparent other than Gecko.
  Florian: Talking about computed style not used style serialization.
  zcorpan: The spec says to serialize as rgb or rgba.

  Florian: We might need to errata color-3.
  astearns: New section goes into color-4?
  Florian: Yes and then see what needs to go as errata in 3.

  <zcorpan> https://drafts.csswg.org/cssom/#serialize-a-css-component-value
  zcorpan: The css spec will use rgb or rgba.
  Florian: Is this computed value serialization?
  zcorpan: It's used for both computed and specified value, I think
           ... depending on context.
  Florian: The OM spec seems to be specifying string level, once you
           are in rgb tells you where to put spaces not when to use
           rgb.

  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=347912
  dbaron: Serialization principles I described to you yesterday -
          serialize to most compatible form between old and new
          syntax.
  dbaron: border-color: transparent goes back to CSS1, and I didn't
          want to suddenly start serializing that as rgba(0, 0, 0,
          0).
  fremy: If you write transparent - we serialize as transparent,
         otherwise we return rgb if specified so
  fremy: because of devtools.
  zcorpan: Fair enough.

  ACTION Florian change from used value time to computed value time
         the resolution of current color for color property only.
  <trackbot> Created ACTION-811
  ACTION Florian reread old OM spec to see what to take from it
  <trackbot> Created ACTION-812

  zcorpan: For color the om spec differentiates between specified
           value and other
  zcorpan: <reads spec>
  <dbaron> border-color: transparent goes back to CSS2, not CSS1:
  https://www.w3.org/TR/1998/REC-CSS2-19980512/box.html#border-color-properties
  <dbaron> but it's still older than css3-color

  ACTION florian test border-color:transparent to see if its
         different
  <trackbot> Created ACTION-813

  Florian: Once I have adjusted my stuff for OM - do we have section
           in both color and OM spec?
  Florian: OM doesn't look like the correct place to specify that.
  astearns: For new things like shape function there is a
            serialization in Shapes spec.
  Florian: Use hooks into CSSOM and put the prose in the color spec?
  zcorpan: File issues for each case?
  Florian: By PR try to fix the OM spec OR migrate it to color spec
           and pull out of OM spec

Interpolating between color spaces
----------------------------------

  <nainar> https://github.com/w3c/csswg-drafts/issues/883
  smfr: Interpolation between color p3 and blue/rgb something.
  Florian: This is what the working color space - in which you do
           color interpolation.
  smfr: Not the same as implementation may pick a color space that
        is different.
  surma: Is the question the bigger color space easy to answer?
  many people: No.
  Florian: Come back after ChrisL has written it up - and then be ok
           with or file issues on it

Animating to/from currentColor
------------------------------

  <nainar> https://github.com/w3c/csswg-drafts/issues/873]
  Florian: We are all interoperable - in transition/animation -
           currentColor you can transition to and from - probably
           should specify this.
  dbaron: This is what we thought we were ok with breaking when we
          decided to change currentColor to a computed value - no
          one was ok with breaking it.
  Florian: We should add sentence to the transition spec where you
           define how to interpolate on color.
  Florian: If you transition to/from current color use numeric value.

  fremy: Doesn't work in edge
  fremy: unless you use transparent.
  dbaron: Bug maybe?
  dbaron: Color is special because currentColor means inherit.
          border-color is most interesting because currentColor is
          the initial value.
  fremy: probably a bug?
  <fremy> xbody { color: rgba(300, 100, 100, 0.5); } xbody { color:
          transparent; } body { color: rgba(0,0,0,0); }
  <fremy> https://jsfiddle.net/byuusg4w/
  <smfr> https://jsfiddle.net/1pt1qzwg/
  <fremy> https://jsfiddle.net/byuusg4w/1/

  gregwhitworth: Maybe our assumption of the usage of currentColor
                 is different from the way it is actually used.
  fremy: Implicit works, specifying currentColor doesn't work.
  gregwhitworth: smfr on yours ours works.
  Florian: The spec doesn't say - and should say something.
  Florian: If you transition to/from current color use numeric value.
  astearns: Are there concerns about interoperability - everyone ok
            with changing to this behavior?
  Florian: If not what other behavior should we considered.

  RESOLVED: Add that if you transition to/from current color use
            numeric value.

Specification for DCI P3
------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/294
  tantek: This is a problem with color we had before - what if
          something normatively references a standard - subsequent
          to that organizations like w3c have specified what they
          mean by open standard.
  tantek: No spec to reference that complies with open standard
          principles - the w3c has a policy of what we should/
          shouldn't reference.
  Florian: Chris meant that there is not that there is no spec to
           point to, but that a ??? spec doesn't exist to.
  tantek: You mean a delta spec?
  Florian: Who owns that spec? DCIP3
  <tantek> FYI: https://open-stand.org/
  <tantek> FYI: W3C Normative Reference Policy
           https://www.w3.org/2013/09/normative-references

  astearns: Proposal to reach out to them to see if some doc could
            be given to w3c as member submission?
  Florian: What Chris has written in github can we inline this?
  tantek: Not doable unless you have read that spec.
  dbaron: What he is talking about is the delta from the DCI p3?
  tantek: I'm taking Chris's word for it.
  dbaron: Has he read it?
  astearns: Who in w3c will be go between?
  tantek: Who owns it? Are they w3c memebrs?
  ???: Who presented this at TPAC?
  dbaron: That's the person Chris mentions talking to at TPAC
  astearns: Not listed as a member.
  dbaron: Maybe it's another membership organization and there are
          ???
  tantek: Unless you are a member you can't submit it.
  astearns: We cant figure this out here - something that Chris
            needs to work through with w3c management.
  tantek: Specially if to implement that keyword you need to
          normatively reference that.
  astearns: That's all we can get to know, thanks for headsup - talk
            to Chris

  tantek: Crossed my radar - apple announced in 2016? the P3 stuff
          and then raised the threshold that this might take off.
  tantek: There was a blog post by cofounder of instagram that they
          will support this - which is a wrap around webview
  tantek: Once you had people using this supporting this becomes our
          issue.
  gsnedders: They had no plan to support this on their website.
  Florian: Yeah but people will take images and reference the colors.

  ACTION astearns to work with Chris to figure out what to do with
         the epc for DCI p3
  <trackbot> Created ACTION-814

  smfr: This is supported in Safari review not behind a flag.
  astearns: Safari doesn't pick up everything in the preview.
  tantek: But web devs can experiment with by downloading the
          preview.
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
 <tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
  <td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
  </td>
 </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>

Received on Tuesday, 14 February 2017 01:21:56 UTC