Skip to content

[css-color-hdr] Why do the new non-rgb/xyz colorspaces use the color() function? #11713

Closed

Description

@weinig

In CSS Color HDR, the new colorspaces all use the color() function notation, even though Jzazbz, JzCzHz and ICtCp are not RGB or XYZ colorspaces.

Way back when, I filed #5887, arguing we should only use color() for additional colorspaces, but at the time it was rejected.

If these are being added to the color() function, does it stand to reason that lab()/lch()/oklab()/oklch() should also be added as well?

Activity

  1. svgeesus commented on Feb 14, 2025

    @svgeesus
    Collaborator

    Fair point, and there is still time to change this if that is what we want.

  2. weinig commented on Feb 18, 2025

    @weinig
    ContributorAuthor

    @svgeesus, I can't tell from your response what you are suggesting is still possible to change.

    Are you saying we should give Jzazbz, JzCzHz and ICtCp their own functions, jzazbz(...), jzczhz(...), and ictcp(...)?

    Or, are you saying we should add color(oklab ...), color(oklch ...), color(lab ...) and color(lch ...)?

    (My personal preference would be the latter, deprecating the existing forms, and also adding color(hsl ...) and color(hwb ...) to the party).

  3. svgeesus commented on Feb 18, 2025

    @svgeesus
    Collaborator

    Sorry.

    Are you saying we should give Jzazbz, JzCzHz and ICtCp their own functions, jzazbz(...), jzczhz(...), and ictcp(...)?

    Yes. These are not implemented (well, color.js parses them and emits them, but no-one depends on that). Ant it makes CSS Color HDR align more with CSS Color 4 in terms of color functions.

    Or, are you saying we should add color(oklab ...), color(oklch ...), color(lab ...) and color(lch ...)?

    (My personal preference would be the latter, deprecating the existing forms, and also adding color(hsl ...) and color(hwb ...) to the party).

    That seems like a lot of testing work for little actual benefit (especially if we then deprecate the other forms).

  4. Crissov commented on Feb 18, 2025

    @Crissov
    Contributor

    If you are in fact going to add separate functions for Jzazbz, JzCzHz and ICTCP, then please leave out the indices! jab(), jch() and icc() (or perhaps itp()) would work just fine.

    In another world, we might have had unified lab() and lch() functions, e.g like lab(… in CIE), lab(… in OK) and lab(… in HDR).

  5. svgeesus commented on Feb 18, 2025

    @svgeesus
    Collaborator

    If you are in fact going to add separate functions for Jzazbz, JzCzHz and ICTCP, then please leave out the indices! jab(), jch() and icc() (or perhaps itp()) would work just fine.

    Good point, Jzazbz in particular is super hard to say in conversation. And we left out the * in CIE L* a* b*.

    On the other hand, there is a separate colorspace called ITP which might be confusing, and icc might be confused with ICC color profiles.

    But on balance yes, simple and readable color function names.

  6. svgeesus commented on Mar 3, 2025

    @svgeesus
    Collaborator

    CIECAM02, CIECAM02-UCS and CAM16-UCS also have Jab so unpronounceable Jazbee names it is, I think.

  7. svgeesus commented on Mar 3, 2025

    @svgeesus
    Collaborator

    Another argument in favor of separating out the non-RGB spaces from color() is RCS. It would be odd to write

    color(from var(--base) jzczhz calc(r/2) g calc(b+180)) to halve the lightness and get the complementary hue. These functions should have their own component keywords.

    jzczhz(from var(--base) calc(j/2) c calc(h+180))

  8. weinig commented on Mar 4, 2025

    @weinig
    ContributorAuthor

    We do already have different constants when using the XYZ colorspaces in an RCS color() function.

  9. svgeesus commented on Mar 12, 2025

    @svgeesus
    Collaborator

    @weinig so the best option seems to be

    give Jzazbz, JzCzHz and ICtCp their own functions, jzazbz(...), jzczhz(...), and ictcp(...)?

    Yes. These are not implemented (well, color.js parses them and emits them, but no-one depends on that). Ant it makes CSS Color HDR align more with CSS Color 4 in terms of color functions.

  10. svgeesus commented on Mar 12, 2025

    @svgeesus
    Collaborator

    PROPOSED: In CSS Color HDR, move Jzazbz, JzCzhz and ICtCp from color() to their own functions, for consistency with CSS Color 4 Lab, LCh, Oklab and Oklch

  11. svgeesus commented on Mar 12, 2025

    @svgeesus
    Collaborator

    @astearns suggest the CfC ends before the next HDR breakout in 2 weeks

  12. weinig commented on Mar 13, 2025

    @weinig
    ContributorAuthor

    Proposal seems good to me. +1.

  13. astearns commented on Mar 17, 2025

    @astearns
    Member

    The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

    Proposed Resolution: In CSS Color HDR, move Jzazbz, JzCzhz and ICtCp from color() to their own functions, for consistency with CSS Color 4 Lab, LCh, Oklab and Oklch

  14. 4 remaining items

  15. svgeesus commented on Mar 25, 2025

    @svgeesus
    Collaborator

    @cdoublev I'm not happy with the grammar productions. The extended <color-function> production links back to CSS Color 5, which means the extended <colorspace-params> becomes invisible. Could you take a look?

  16. svgeesus commented on Mar 26, 2025

    @svgeesus
    Collaborator

    Re-opening as there are still pending edits and WPT to write

  17. svgeesus commented on Jul 19, 2025

    @svgeesus
    Collaborator

    Closing as spec is up to date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions