Shared lexicon schemas for long-form publishing on AT Protocol. Uses typescript to json via prototypey.

Fork 3

Standard Site Colors Should Be CSS Colors #1

Open

mrpowershell.com 10mo ago

Open opened by

mrpowershell.com 10mo ago

I firmly believe that standard site colors should simply be CSS colors.

At present, the spec indicates that colors would be stored as distinct RGB values.

I believe this is both limiting and wasteful.

I believe it is limiting in the CSS colors can be far more sophisticated than just RGB.

I believe it is wasteful because the hex representation takes a lot less space than putting it in three named json properties.

I'd also go a small notch further: anytime standard.site is thinking of closely duplicating something that is a standard CSS type, I believe it should probably just a CSS value.

awarm.space 10mo ago

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.

mrpowershell.com 10mo ago

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 )