- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Dec 2020 19:02:06 +0000
- To: public-houdini-archive@w3.org
> > Something like: CSSRGB({r: 0, g: 128, b: 255}) or CSSRGB({rPct: 0, gPct: 50, bPct: 100}) (not personally a fan of the abbreviation but trying to keep it succinct)
> This creates unnecessary error conditions: what happens when both r and rPct are specified?
That could be trivially resolved. You either raise an exception or decide which one wins.
Using an initialization dictionary also allows you to mix and match, e.g. `CSSRGB({r: 0, gPct: 50, b: 42})`
That said, I agree that 0-255 is a relic, but it is in common use. I'm in favor of making the API more forward-looking, but want to maintain backward compatibility with legacy code as well to ease the transition. I'm also concerned that if we go with pure 0-1 floating point that we make sure all the (0-255)/255 values can be accurately represented by JS numbers so they at least can round-trip without rounding errors (I think that's the case, but someone should check). e.g. if someone does `new CSSRGB(42/255, 42/255, 42/255)` and we have an accessor that returns a color channel in the 0-255 range, it needs to return 42, not 42.0000001 or 41.99999999. There's also the question of how these serialize, would the preceding example serialize as `rgb(42, 42, 42)` or `rgb(16.47%, 16.47%, 16.47%)`? css-color-4 specifies the former.
Even if we decide that the only values are r, g, and b in the 0-1 range, using an initialization dictionary is more readable, and is much more future-proof. It's simply a more forgiving pattern. Not to mention, it's endorsed by the TAG: https://www.w3.org/TR/2020/NOTE-design-principles-20201110/#prefer-dict-to-bool and https://www.w3.org/TR/2020/NOTE-design-principles-20201110/#naming-optional-parameters
Actually, the more I think about the serialization issue, the more I think the CSSRGB constructor should only take values comparable with the CSS `rgb()` function. This is an object model meant to represent the `rgb()` function as it stands after all, not an opportunity to invent something new. So I'm voting in favor of option 4 above (with a dictionary constructor, and the ability to take percentages as well as numbers in the 0-255 range). New ways of defining colors should be used in classes that represent the CSS constructs that allow them, e.g. `CSSColor()` that takes arguments like `color()` does.
--
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-744644291 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 14 December 2020 19:02:08 UTC