I hear that strong preference on including data as an object. I also ask you to consider the performance / complexity tradeoff. If it was limited to hex RGB, this would be fine. But component rgb....
First up, usability:
Hex RGB is definitely the standard here. Almost every UI platform supports '#4488ff'. Putting it into components makes for extra work for the developer on the way in and the way out.
Let's presume we limit the syntax to hex rgb for the next bit: data transmission:
"red" + "green" + "blue" is an extra 12 bytes right there. shorten it to RGB and you take that down to 3 bytes, but then you the quoting around keys to worry about, plus the colon (9 more bytes).
That's more "over the wire" than required, by far. As written, 21-26 bytes to send the data, versus 7. That would be sent across the jetstream and duplicated into every pds. Surely that's nothing compare to text posts, but it also adds up.
I'm a big fan of "as simple and open as possible" lexicons, so I think just suggesting css color and taking a single value the right long term answer here, because it has a whole standards committee behind it and support from almost every web based UI framework.
But if we want to keep it "very standard", I'd still think HexRGB should be the default, and component RGB would be the exception.
If we want it to be very fast, then standardizing on a uint32 representation of RBG or RGBA would be quicker (and roughly the same amount over the wire, depending on the color used).
If we're finding the sweet spot between usability and insanity, hex color.
If we're being as long term open as possible without taxing the developer, css color
If we want the developer to pay a tax each time they use the color, keep it in pure component form.
(apologies for the strong feelings here - been doing graphics work long enough to know how important simple choices like these can be on framework adoption )
standard.site
mrpowershell.com
awarm.space
I think I have a pretty strong preference for including data as an object instead of a string where possible. It means that users of these records don't have to do further parsing to check that values are valid, or to extract out the data they need, which they may have to do if they're working in an environment without a CSS engine, (native apps? TUI's maybe?).
I agree limiting to just RGB is an artificial constraint, the theme properties are set up as a union to explicitly allow future extension, so if there are specific color values people need, we could absolutely add em. In the long term it's possible that a color lexicon would have a better home somewhere else, and that could plausibly fully represent CSS colors.
In general, I don't know how much is borrowable from CSS, it's got a much wider scope than standard.site, and I think allowing for all those possibilities makes coordination harder.