Peter Linss

> > 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)...

> 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...

> > Using an initialization dictionary also allows you to mix and match > We have numeric types already for precisely this reason - if you want percentages, you can...

> all arguments (besides a) are required (assigning an arbitrary default can theoretically make any argument optional, but in this case that's externally inconsistent) In JS all arguments are effectively...

> Both throw. Those are required arguments in CSS, and there's no particularly good reason to change that in the JS representation, I believe. There's not really a meaningful sense...

> Wait, is that all it is doing? An object model of the sRGB-only rgb() function? I don't understand how that is useful. Having not seen the actual spec prose...

Also, to be clear, I'm perfectly happy for the generic Color classes to take simple bare numbers in their constructors. e.g. should there be a RGB Color subclass, `new RGB(0,...

> 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...

> If you pass it RGB(1) you can reasonably forward fill GBA with 0,0,1 (sigh) I'm not saying it *can't* be done, I'm saying it **shouldn't**. It violates the principle...

> We’ve crossed wires here. Agreed, I read "forward fill" as filling in missing arguments from the front, I also misread your example as `RGB(1)` creating blue, sorry for the...