Discussion: goals of a standard color package

[avh4]

Summary (will be updated throughout the discussion)

Questions to answer:

• What belongs in the package?
  • Phase 1 (immediately)
    • [x] data type for representing colors
    • ~alias for RGB record?~: No, it's good enough to have functions that provide these records, and keeping internals private gives us implementation flexibility for now.
    • [x] private, opaque type?
    • common conversions
    • which color spaces? / which formats?
      • [x] RGB / RGBA
      • [x] hex string
      • [x] HSL / HSLA
      • [x] other?: Not in v1.0.0
    • [x] a default color palette?
  • Phase 2 (after a bit more design thought)
    • [ ] conversion between color spaces?
    • [x] are we representing absolute colors (sRGB, CIEXYZ, etc) or relative colors (RGB, HSL, etc)? or do we need both?
      • HTML, SVG, CSS all specify sRGB, so there's no need to model relative color spaces
    • [x] manipulation of colors?: Will target v1.1.0
  • Phase 3 (not urgent)
    • [x] more multiple palettes?: probably not
• [x] How should colors be represented?
  • ~RGBA as integers~: is not accurate enough to represent values in other color spaces
  • RGBA as floats
  • handle multiple possible formats internally, and convert as appropriate
  • ~HSL or CIEXYZ~: RGB makes sense since it's what it will be eventually converted to for almost all web dev uses
  • ~other options?~: none suggested
• [x] other questions...

Use-cases

• Manipulating colors should be fast enough (avoid unnecessary conversions if possible)
  • How fast is fast enough?
• It should be easy for users to create colors by any means and use them for any purpose
• It should be possible (and ideally easy) for package authors to create new packages that interoperate with standard colors

[avh4]

My thoughts at the moment:

• there should be a standard data type for Color that should be preferred by all packages that use colors as input or output
• the Color data type should not expose its constructors to ensure that "Color" remains an abstract interface
• the package should provide simple functions for converting from/to standard formats (like 0-255 RGB, and hex strings)
• I agree with Rupert (discourse) that it's probably best to represent internally as RGB to avoid unnecessary conversions
• I think the API should hint at the distinction between relative and absolute color spaces (e.g., RGB vs sRGB) to help web developers avoid confusion, but also should not require understanding of that distinction to use the API

I think the above are important to do quickly and make available and could be an initial release.

Beyond that, I think there are good questions about how best to handle other things like default colors, palettes, color manipulation, and alternate colorspaces. My thoughts at the moment:

• Color manipulation would be good to standardize and put in the module, but it probably takes a bit of design and doesn't need to be in the initial version of this package.
• Palettes should probably be separate packages, but could be encouraged to name the modules Color.Palette.<Something> for consistency
• Unusual colorspaces, like CIELAB, CIECAM02, CIEXYZ, Munsell, etc should probably start as separate packages, and probably stay that way unless they turn out to be very generally useful

[2mol]

I agree with the direction of the discussion.

As per the other thread, a record type of floats for RGBA channels seems great. I'm unsure about making the type opaque or not. The tradeoff: If it's opaque, you can clamp the channels between 0 and 1 when you construct/convert a color value, so you can try to guarantee to never construct invalid colors. Plus you can at any time change the internal representation! I like this. But you lose a little bit of convenience and transparency.

To give my minimal list of what I think belongs into particular package:

1. Color types for RGBA and HSLA, and (ideally lossless) conversion functions from one into the other.
2. Conversion to hexadecimal strings.

For me, that already goes a long way.

[avh4]

There is now an API proposal for further discussion: https://github.com/avh4/elm-color/issues/4

But feel free to comment further on this issue, and I will monitor and incorporate it to the appropriate place.

[avh4]

I think everything here has been incorporated elsewhere.