`color` vs `value` attribute

[LeaVerou]

When rewriting <color-swatch>, I opted for a color attribute. However, I’m not so sure it was a good idea. value is far more common across HTML elements, and there are libraries and frameworks that work out of the box with elements that follow the convention of .value property + input event for user-initiated changes (e.g. Vue’s v-model). Also, color is a Color, so conceptually since the attribute is specifying a string, value seems more fitting.

So what about:

• value attribute, which gets reflected into a value property
• color property that contains a Color instance if this.value is a valid color, or null otherwise.

This would be across all components whose value is a color (<color-inline>, <color-swatch>, <color-picker>).

[DmitrySharabin]

Do I get it correctly that the color property will become a getter in that case? Can authors set Color as a value of the value attribute?

In general, I think it's good to be consistent with the platform and let authors use the elements the way they used to. I think it's a win-win.

[LeaVerou]

No, I think it's okay for authors to set either of them, and they should be kept in sync.

I was also thinking that space has a similar issue: Authors actually set a space id via the attribute, but it gets converted to a color space object. We should instead have a spaceId property (that reflects from the space attribute) and a separate space property that is a ColorSpace object (and authors can set either).

[LeaVerou]

For inspiration, I was using <input>’s valueAsDate/valueAsNumber properties, and that's exactly how they work: https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement

[DmitrySharabin]

I was also thinking that space has a similar issue: Authors actually set a space id via the attribute, but it gets converted to a color space object.

I believe we have a bit more, e.g., stops.

[LeaVerou]

Related: https://github.com/nudeui/element/issues/24