Reorganization of data for <color>

[teoli2003]

This is part of openwebdocs/project#92.

Problems to solve

The compatibility data for <color> and for the specific function pages (like rgb()) are difficult to read.

1. On <color>, information is not ordered in a coherent way. All information is scattered around. For example, the information pertinent for rgb() is at the 3rd line from the top, the 3rd and 4th line from the bottom. It is also not obvious to which functions an entry like "Space-separated functional notations" applies.
   

2. On MDN pages for each function returning a <color>, like rgb(), we need to add several browser compatibility tables:
   

3. In the future, the problem will get worse: there are new functions in the spec not yet implemented (oklab() or oklcb()) and we already miss the OS-linked color keywords.

Cause of the problem

The problem comes from the fact that all entries are at the top-level hierarchy.

Proposed solution

We should introduce an additional level: one for each color notation or functions: rgb(), rgba(), color keywords, transparent, currentColor, color-mix(), …

That way we can put the evolution of the feature into it. For example, we will be to list under rgb() that it started to accept a fourth parameter at some point, float values at another, and space-separated syntax for parameters at a third one.

The data in <color> will be easier to read, and only one table will be needed on each of the feature pages. Also, we will be able to link to the spec and to mdn page correctly.

Here is the proposed hierarchy:

"css"
    "types"
        "color"  // <color>
            "color"  // color() (to define color-profile)
            "color-contrast" // color-contrast()
            "color-mix" // color-mix()
            "currentcolor" // currentColor keyword            
            "hsl" // hsl()
                "alpha_parameter"
                "space_separated_parameters"
            "hsla" // hsla()
                "space_separated_parameters"
            "hwb" // hwb()
            "color_keywords" // red, blue, cyan, …
                "rebeccapurple"
            "lab" // lab()
            "lch" // lch()
            "rgb" // rgb()
                "alpha_parameter"
                "float_values"
                "space_separated_parameters"
            "rgba" // rgba()
                "float_values"
                "space_separated_parameters"
            "rgb_hexadecimal_notation" // #RGB and #RRGGBB
                "alpha_hexadecimal_notation": // #RGBA and #RRGGBBAA
            "transparent": // transparent keyword

cc/ing @Elchi3, @Rumyra, and @ddbeck

[Rumyra]

I'm on board with this! And the content amends as well. Recently adding hwb() made me realise that we're going to struggle with the current format (both bcd & content) as the new color features are landing 👍

[Elchi3]

This makes sense to me, too!

Lower-level structural/hierarchical/namespace changes in BCD are possible, see the BCD readme on the semver policy:

You should expect lower-level namespaces, feature data, and browser data to be added, removed, or modified at any time.

However, we might want to note the PR/this issue in the release notes in case anyone relies on this (unprotected) lower-level structure for css.types.color.

[teoli2003]

This landed, so I can close this.