- From: markuslangl via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Dec 2021 09:55:26 +0000
- To: public-design-tokens-log@w3.org
Thank you very much for your feedback!
> I'm wondering if something like `modified-color` would be enough to address the examples noted at the end of your message. Or if we might need a few.
That's a great point! It might become probably a bit confusing what the expected result is, if users add e.g. `hue` and `green` at the same time to modify a color.
Maybe it could make the implementation easier, if there were several `color` composite types available, which limit the usage of the modifications? For example:
| Composite type | Allowed keys in value object |
| -------------- | ---------------------------- |
| `color-rgba` | `color`*, `red` or `red-relative`, `green` or `green-relative`, `blue` or `blue-relative`, `alpha` or `alpha-relative` |
| `color-hsla` | `color`*, `hue` or `hue-relative`, `saturation` or `saturation-relative`, `lightness` or `lightness-relative`, `alpha` or `alpha-relative` |
| `color-hsba` | `color`*, `hue` or `hue-relative`, `saturation` or `saturation-relative`, `brightness` or `brightness-relative`, `alpha` or `alpha-relative` |
| `color-fulness` | `color`*, `tint` or `tint-relative`, `shade` or `shade-relative`, `tone` or `tone-relative`, `alpha` or `alpha-relative` |
(`*` declares that a key is a required value for the type)
With this scheme, it might also be possible to avoid the `modify` wrapper to have less markup for the same result:
```json
{
"background": {
"type": "color-rgba",
"value": {
"color": "{color.base.red}",
"alpha": 0.1,
}
}
}
```
This could also become very powerful when these values could appear on all places where colors are defined, like e.g. the `border` composite type:
```json
{
"alert": {
"opacity": {
"background": {
"value": 0.1
},
"border": {
"value": 0.3
},
},
"danger": {
"base": {
"type": "color",
"value": "{color.base.red}"
},
"background": {
"type": "color-rgba",
"value": {
"color": "{components.alert.danger.base}",
// Set opacity/alpha to 10%
"alpha": "{components.alert.opacity.background}",
// Reduce red by 10%
"red-relative": -0.1,
}
},
"border": {
"type": "border",
"value": {
// Using composite value instead of #RGBA
"color": {
"type": "color-hsla",
"value": {
"color": "{components.alert.danger.base}",
// Set opacity/alpha to 30%
"alpha": "{components.alert.opacity.border}",
// Increase saturation by 50%
"saturation-relative": 0.5,
}
},
"width": "{border.base.m}",
"style": "{border.base.style}"
}
}
},
}
}
```
### Advantages and Disadvantages
The advantages with this versions could be:
* The available options are limited to the specific color space and avoid conflicting states
* Relative and absolute values can be used at the same time
* References can be used for all values, not just the color itself
* New color spaces could be added in future spec versions easily without modifications to the existing types
* These types could be easier discovered than `modified-color` when using auto-complete (e.g. if users type `col|`, they can see `color`, `color-rgba`, `color-hsla`, etc.)
Disadvantages are:
* It might become more work for vendors to implement the different types
* Modifications to colorfulness (tinting, shading, toning) are currently not supported natively by CSS and would require processors like e.g. SASS or [postcss-color-mod](https://github.com/csstools/postcss-color-mod-function)
### Open question: Value scale
One open question would be, which units and scale would be most intuitive for relative and absolute values? A few options come to mind:
1. Consistent percentages on a scale from `0` to `100`?
2. Consistent percentages on a scale from `0` to `1`?
3. Consistent percentages based on given unit (e.g. number between `0` and `1` or string with percent sign for value between `"0%"` and `"100%"`)?
4. Consistent values on a scale from `0` to `255` (to match the hex scale)?
5. Different for each of the values as it makes more sense (e.g. `red` in percentage from `0` to `100`, `hue` in degrees from `0` to `360`, ...)?
### Open question: Nested color composites
The second open question would be, is if the `color` type should be able to _always_ be replaced with these new Color composite types, even inside the types themselves?
For example, should the following example result in `text-color` value of `#00FFFF7F`?
```json
{
"text-color": {
"type": "color-rgba",
"value": {
"color": {
"type": "color-hsla",
"value": {
"color": "#ff0000",
"hue": 180
}
},
"alpha": 0.5
}
}
}
```
Unfortunately, this has potential for wrong inputs when non-color types would be added to the `color` value:
```json
{
// Example with invalid content
"invalid-text-color": {
"type": "color-rgba",
"value": {
"color": {
"type": "font",
"value": "Fira Sans"
},
"alpha": 0.5
}
}
}
```
In our opinion, it would be very powerful and flexible for designers to define colors like this. We could define some base colors and generate most other colors in the tokens based on these.
If parsers would ignore invalid values such as `"type": "font"`, or show error messages when creating or reading files, the benefits might be worth the potential for errors.
> when I, as a designer, asked our dev's to include different opacities as design token options so that we can modify base colours. I was told that there wouldn't be an easy way to do this.
We're mainly seeing this from the perspective of Web development, but would love these definitions to be interoperable with all other platforms.
Are there different usages and definitions for other platforms like iOS or Android, that would limit the functionality of these color composite types?
--
GitHub Notification of comment by markuslangl
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/88#issuecomment-997768873 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 December 2021 09:55:28 UTC