Closed github-actions[bot] closed 4 months ago
This pull request is automatically being deployed by Amplify Hosting (learn more).
Access this pull request here: https://pr-1190.d16eby4ekpss5y.amplifyapp.com
This pull request is automatically being deployed by Amplify Hosting (learn more).
Access this pull request here: https://pr-1190.d1ouz7xofr5p4l.amplifyapp.com
I know that in CSS, linear-gradient()
is not actually a <color>
, it’s an <image>
.
I guess that it’s normal then if it’s not interpreted has a color.
I wonder if tinycolor2 should still be used as it’s a bit outdated and it does not support most recent CSS color syntaxes. I stumbled across a library called Color.js that does support newly introduced syntaxes, you might want to have a look at it.
Yeah I'm a fan of that library, please raise an issue for migrating to it to support things like oklab/oklch etc, I foresee this becoming more common and I know a couple of color nerds that would love for SD to support it in its transforms (@mikekamminga ). I won't have time for it for v4 but PRs are welcome still, seems to me like it wouldn't be a breaking change if color.js supports everything tinycolor2 does except more.
[…] seems to me like it wouldn't be a breaking change if color.js supports everything tinycolor2 does except more.
Unfortunately, I noticed that a few (non-standard) things that tinycolor2 supports are not supported by Color.js. Since the nature of Color.js makes it extensible, there could be some things done to support some of them, but I doubt that everything could be covered.
[…] seems to me like it wouldn't be a breaking change if color.js supports everything tinycolor2 does except more.
Unfortunately, I noticed that a few (non-standard) things that tinycolor2 supports are not supported by Color.js. Since the nature of Color.js makes it extensible, there could be some things done to support some of them, but I doubt that everything could be covered.
Shall we raise a separate issue for this? Can you share which things are unsupported, we can decide whether we want to add backwards compat or not, I think unprefixed hexadecimals is an example of something we could probably just decide to stop supporting, and folks can always write a custom value transform to put the # in front of such values if they really need them
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to v4, this PR will be updated.
⚠️⚠️⚠️⚠️⚠️⚠️
v4
is currently in pre mode so this branch has prereleases rather than normal releases. If you want to exit prereleases, runchangeset pre exit
onv4
.⚠️⚠️⚠️⚠️⚠️⚠️
Releases
style-dictionary@4.0.0-prerelease.28
Minor Changes
4225d78: Added the following transforms for CSS, and added them to the
scss
,css
andless
transformGroups:fontFamily/css
-> wraps font names with spaces in'
quotescubicBezier/css
-> array value, put insidecubic-bezier()
CSS functionstrokeStyle/css/shorthand
-> object value, transform to CSS shorthandborder/css/shorthand
-> object value, transform to CSS shorthandtypography/css/shorthand
-> object value, transform to CSS shorthandtransition/css/shorthand
-> object value, transform to CSS shorthandshadow/css/shorthand
-> object value (or array of objects), transform to CSS shorthandThe main intention here is to ensure that Style Dictionary is compliant with DTCG draft specification out of the box with regards to exporting to CSS, where object-value tokens are not supported without transforming them to shorthands (or expanding them, which is a different feature that was added in
4.0.0-prerelease.27
).Patch Changes
linear-gradient(...)
) are now ignored by the builtin color transforms filter functions.