- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Mon, 14 Dec 2020 20:34:27 +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.
Indeed, you can solve all unnecessary error conditions by raising an error, but that doesn't make them good practice. It's far better to avoid creating the error condition in the first place.
Deciding which one wins is the kind of arbitrary decision that makes APIs feel unpredictable and hard to learn.
> 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.
I just ran `for (let i=0; i<256; i++) { let a = i/255; console.log(a * 255); }` and it seems to only log integers. Not sure if there's a compiler optimization at play though.
> 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: [w3.org/TR/2020/NOTE-design-principles-20201110/#prefer-dict-to-bool](https://www.w3.org/TR/2020/NOTE-design-principles-20201110/#prefer-dict-to-bool) and [w3.org/TR/2020/NOTE-design-principles-20201110/#naming-optional-parameters](https://www.w3.org/TR/2020/NOTE-design-principles-20201110/#naming-optional-parameters)
Please note that the TAG guidelines you link to (both of which I'm aware of and have even [taught](https://www.youtube.com/results?search_query=js+ux+verou)) do not apply here. They are both about optional arguments, which these are not. Also, the first one is mainly about booleans, edited recently to generalize to all **optional** primitives. Indeed, avoiding boolean positional arguments is one of the most basic API design principles (they are called "boolean traps" for good reason). However, red, green, and blue, are numbers with an established meaning, an established order, and all of which are mandatory.
That said, there is less of an established order in other color spaces (e.g. LCH vs HCL), so for consistency, it would make sense to use named parameters here too.
--
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-744694213 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 20:34:29 UTC