Standardise name + syntax of color formats, alphabetise

[dcog989]

Label / name and syntax of color formats used by Color Picker adjusted to conform with https://www.w3.org/TR/css-color-4/ where specified.

Also, alphabetised list of color formats to assist user in selection.

PR Checklist

• [x] Closes: N/A
• [x] Communication: I've not "discussed this with core contributors" - don't know who they are or how to contact
• [x] Tests: Added/updated and all pass
• [x] Localization: All end user facing strings can be localized
• [x] Dev docs: Added/updated N/A
• [x] New binaries: Added on the required places N/A

[lhecker]

While LLMs may judge this reliably in the future, I believe it is not yet the time where such a discussion is something we can rely on. As such I would disregard the LLM'ss findings for now.

Regarding W3's spec, to my knowledge their choice of OKLCh stems from here: https://github.com/w3c/csswg-drafts/issues/7880 More precisely, it was found that Björn himself used "OKLCh" in his blog series: https://github.com/w3c/csswg-drafts/issues/7880#issuecomment-2508790658

However, that comment is wrong. What Björn actually wrote was "OkLCh", because all variants of his color space begin with "Ok", not with "OK". So, the W3 spec is also flawed. That's not unreasonable, as it is written by mere humans as well, and mistakes happen. It's a subjective choice to begin with too.

I suggest naming the space "OkLCh", because that's how Björn called it here (first paragraph): https://bottosson.github.io/posts/colorpicker/#okhsl

[dcog989]

that comment is wrong.

Without being part of the spec group, you cannot know why the spec group chose OKLCh. But if you want to submit an issue and the spec is changed as a result, then labelling here can be updated to match.

Also, Color Picker allows full customisation, so anyone who doesn't like the spec can change labelling to whatever they want.

[lhecker]

@dcog989 The spec has been changed: https://github.com/w3c/csswg-drafts/commit/a43e05d549e271be03d246b5b5231655a2ada4f8

[dcog989]

@lhecker - thanks. I'll update this PR tomorrow.

[crutkas]

so looking at this PR, correct me if i'm wrong, this just just removing a toupper and adjusting a single char?

https://github.com/microsoft/PowerToys/pull/39461/files#diff-614dfa0d33bd1e4d5f762d35249caf9f9d3fcaeeeea26c671c9bb30e40717ab8R616

why do we need the refactor the switch statement?

[dcog989]

@crutkas, Hi. As per comment in code, alphabetised to aid user selection.

We're going from Oklch > OKLCh (original spec) > OkLCh (revised spec incoming) + remove toupper so we can see the correct case (or whatever the user chooses via options).

[crutkas]

I think this may break some setting stuff. Something feels broken.

• not seeing casing
• OKLCH just isn't displaying
• the switch statement adjustment feels unneeded

This was from d738544 from break debug build from your branch:

Here is a rtm 0.91 with a fresh app data folder

[dcog989]

OK, thanks for the review / feedback. I'll investigate - try and build / test locally before offering an update.

[dcog989]

@crutkas - I haven't been able to build locally, so cannot test, so abandoning PR.