Re: [css-houdini-drafts] [css-typed-om] Inputs for the CSSColorValue constructors (#1014)

> >  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 just pass a CSS.percent(10) as the value.

Fair enough.

> I don't think an initialization dict, in general, is the best pattern here - most of the arguments are required, and there's already a well-known and established order for them, coming from CSS (and re-expressed right in the name). So I'm pretty confident positional is still the right way to go here, at least for the simple functions. (color() might get a different treatment.)

I disagree. I have no issue with also accepting positional arguments. But I want to push back on them all being required. e.g. does `let x = new CSSRGB()` throw an exception or is it simply `new CSSRGB(0, 0, 0)`. Similarly, what if an author calls `new CSSRGB(42)` should that throw or just be `new CSSRGB(42, 0, 0)`?

> >    So I'm voting in favor of option 4 above

> Given that taking raw numbers is a pure convenience (rather than only taking the CSSStyleValue objects that it'll expose post-construction), I'm really loathe to do tricky stuff like that and have the numbers be interpreted in different ways depending on the function. It's just begging for people to hold wrong. My current spec text is doing option 2 (raw JS numbers are always 0-1 percentages, but CSSRGB accepts CSS.number(127) as well).

But that's actually inconsistent with your "passing a raw JS number is equivalent to passing a CSSUnitValue(x, "number")" so will cause even more author confusion IMO. I see no reason why `new CSSRGB(100, 150, 200)` should yield any different result than `rgb(100, 150, 200)` in CSS. Anything else is asking for trouble. As I said, we're modeling the existing `rgb()` function here, not inventing something new.

Frankly if you interpret bare numbers as 0-1 you *are* doing something tricky and interpreting them in a different way for this function, interpreting 0.5 as equivalent to CSS.number(127) rather than CSS.number(0.5) like you do *everywhere else*.

So let me make a concrete proposal:
```
dictionary CSSRGBInit {
    CSSNumberish r = 0; 
    CSSNumberish g = 0; 
    CSSNumberish b = 0;
    CSSNumberish a = 1; 
};
interface CSSRGB {
    constructor(optional CSSNumberish r = 0, optional CSSNumberish g = 0, optional CSSNumerish b = 0, optional CSSNumberish a = 1);
    constructor(optional CSSRGBInit init = {});
    ...
};
```
Both bare numbers and CSS.number() are interpreted the same as if they were specified in `rgb()`.

This allows for author convenience, is succinct, is consistent with CSS and should be consistent with other CSS color object constructors.

(I don't have an issue if you want to make a new type restricting the values to double (or even octet), number, and percent types, rather than CSSNumberish, or just define other values to throw exceptions.)

-- 
GitHub Notification of comment by plinss
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-744744849 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 22:16:32 UTC