[css-houdini-drafts] [css-paint-api] Enable inputProperties to provide full descriptors. (#924)

EisenbergEffect has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== [css-paint-api] Enable inputProperties to provide full descriptors.  ==
I was catching up on how various Houdini specs were progressing, reading through [CSS Painting API Level 1](https://www.w3.org/TR/css-paint-api-1/) and [CSS Properties and Values API Level 1](https://drafts.css-houdini.org/css-properties-values-api-1/). There's something that doesn't sit well with me...

It seems that properties need to be declared in two different places, using two different API, in order to implement a custom paint. First, one needs to declare the property names in the `inputProperties` static getter. Second, one needs to provide property descriptors using the `CSS.registerProperty` API.

This causes a couple of problems:
* The community cannot share custom paints as a single script solution.
* Maintenance of custom paints is more complicated and error prone, as changing the paint requires editing of properties in two different locations and repeating string constants in two different places.
* By design, it forces low-cohesion, which is a standard metric that identifies poor software design.
* This isn't very intuitive (nor ergonomic).

I understand the independent value of having the `CSS.registerProperty` API. I'm not proposing that we remove that. I'd like to propose that we allow the `inputProperties` getter to return `(string | PropertyDefinition)[]`.

In short, I'd like to be able to do this:

```JavaScript
export class MyPaint {
  static get inputProperties() {
    return [
      '--my-property',
      {
        name: '--my-other-property'
        syntax: "<length>",
        initialValue: "0px",
        inherits: false
      }
    ]
  }
}
```

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/924 using your GitHub account

Received on Thursday, 1 August 2019 21:49:30 UTC