Re: [css-houdini-drafts] [css-typed-om] Inputs for the CSSColorValue constructors (#1014)

> It sounds like you have specific differences in mind, since you are asserting that they are small. Could you please share them with us?

I think the biggest obvious fix would be to use raw JS numbers for channel values, rather than CSSNumericValue objects. TypedOM numbers aren't *too* annoying to use, so long as they're CSSUnitValues (just an extra indirection thru the `.value` property, and I made sure you can even directly set a raw JS number so you only need to do the indirection when reading), but they could still be better.

(Tho, having a real angle type, instead of having to choose between setting a raw JS number representing either radians or degrees, is nice.)

*Possibly* a change would be to have all the color spaces live in one class, rather than separate classes per function. That would probably require doing some magic tear-offs, tho, like your Color.js does, which we try to avoid when possible in JS APIs, as it makes lifetime management more complicated. Unsure if this would be a net positive or not.

Turning it around tho, it seems like you're asserting the differences would be large? If so, what would they be? It's very possible that we could add most or even all of what you want to see!

> Nobody is asking for unimplementable, complicated "tons of bells and whistles", but for the existing author use cases to be considered. There is a lot of prior art on this.

I didn't say "unimplementable" *or* "complicated". ^_^ I'm referring to the implicit assertion y'all are making that there are a lot of things we'd want in a Color library that, for whatever reason, aren't appropriate for the Typed OM classes. If you or anyone else would like to demonstrate those things, and we can see that we, indeed, would *not* want to include them in the Typed OM classes, feel free! Currently I don't believe there are, but I'm not the most knowledgeable about this space; I'm not, however, willing to accept a priori that the Typed OM classes *must* be more limited by their very nature, making them unsuitable for this sort of thing.

I'm not being sarcastic in any way - please prove me wrong. I'm just operating off of the information I currently have and my own intuitions, same as any of us are.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-840664471 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 May 2021 16:09:07 UTC