- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Dec 2020 01:38:40 +0000
- To: public-houdini-archive@w3.org
> 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 optional. One way or another you have to define what happens when an author uses `new CSSRGB(42)`, because nothing's stopping them from doing it. If you don't specify the behavior, we'll have interop bugs. In your argument above, throwing an exception is not necessarily best practice and it's better to avoid the error condition in the first place, I agree. Hence reasonable defaults, e.g. 0 for color channels, 1 for alpha. > You feel so strongly that the function should mirror the semantics of rgb(), yet you are opposed to it using positional arguments, just like rgb(). 🤔 I'm explicitly **not** opposed to positional arguments, see my proposal above. I just want the option to use an initialization dictionary. What I *do* feel strongly about is not redefining the behavior of a bare number for this one constructor. Keeping it consistent with a theoretical color object model isn't as valuable as keeping it consistent with CSS syntax that's been in use for over 20 years. Another advantage of an initialization dictionary is that it does let the author opt-in to a different behavior for bare numbers, by specifying them in a different dictionary slot (If that's a case we really need to support, after all, is it worth adding it to save them writing `*255`?). > Please note that color(srgb) uses the 0-1 range when provided with bare numbers. Are we really going to have two different sRGB objects with components in different ranges? Yes. CSS already has them. This is the *CSS*OM, not a *color* OM, the need here is to provide an object model for CSS constructs, in this case `rgb()`. It's a CSS value, not a general-purpose color object. The object's constructor and behavior should match the usage in CSS. The argument to the constructor for CSSColor should match CSS `color()`, etc. I'd love to see a generic color object model. And if we create one I'm happy for that to use floats and do away with the 0-255 legacy there. But that's not the scope of this issue or module and we shouldn't let this scope-creep into one. > We could accept an array OR an object literal I don't see any value in accepting an array. I'm not seriously opposed, but unless there's precedent or alignment with other CSS color constructors I'd rather not invent another new thing here. In fact, we may want to reserve supporting an array in case the `rgb()` function ever gets list-like capabilities. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-744979215 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 01:38:41 UTC