- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Dec 2020 18:53:01 +0000
- To: public-houdini-archive@w3.org
> I'd prefer to reduce the keystrokes and the payload. new RGB(0.5) should forward-fill with 0, 0, 1, the common-sense defaults. The short-hand for blue: 1 is new RGB(0,0,1), shorter than new RGB({ b: 1 })
That's not now JS works, if the constructor is expecting `RGB(r, g, b)` and you call it with `RGB(1)`, you're passing `(1, undefined, undefined)`, shifting arguments around is a completely unexpected behavior.
> But Houdini has been developing for a while and I can easily imagine another 5(ish?) years waiting for a proper Color API
And Houdini will continue developing for many years to come. It's all modules that can be implemented independently. There's no reason to expect defining a proper Color API, independent of the CSSOM would take another 5 years, or that it would, in fact take any longer than trying to define a CSSOM that conflates CSS constructs with generic colors.
In fact, as this thread demonstrates, mixing the two concepts is (and will continue to be) a source of contention that will dramatically slow the process. Having a CSSOM that's simply CSS, and a Color API that's just color, splits the concerns and lets each develop at their own pace, focusing on their own needs. Believe me, we'll get a Color API much faster if it's not carrying around 25 years of CSS baggage. We'll also get a reasonable CSSOM faster if we don't try to solve all of color in it.
--
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-745494255 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 December 2020 18:53:02 UTC