- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 May 2021 04:57:54 +0000
- To: public-houdini-archive@w3.org
> (And I solved it, by just saying that the Typed OM always represents values as 0-1 or %s; CSS's 0-255 range on RGB is just a weird CSS text-syntax thing.) And that's not a good solution. As I said before, the goal of the CSSTypedOM is to represent CSS constructs accurately and faithfully. A class to represent a CSS `rgb()` function should take the same arguments in its constructor as a `rgb()` function does. Doing anything else is not solving the goals of the CSSTypedOM. These classes should be focused on modeling CSS syntax first and foremost. The design question here isn't "which range of numbers do we take in this one constructor", it's "what's the purpose of this API". It's the second question that should be informing the answer to the first. Trying to combine CSS OM with a generic Color class at this point (i.e. without having a well-designed API surface of a generic color class, or even a fully-formed CSSTypedOM API), is a premature optimization that leads to bad design decisions. Those are two very different beasts. Combining them without the big-picture of the best API surface for each is a mistake. Adding color manipulation functions to the CSSTypedOM color classes may very well be a nice convenience for authors, it also might make an API surface that's not performing either job well because it's trying to serve two different functions. As I said, I'm not opposed to combining the functionality in principle, but I am very much opposed to starting with the premise that we *must* do so. And any compromises we make *now* trying to serve that end are a mistake. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1014#issuecomment-837813157 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 May 2021 04:57:55 UTC