Define gradient color stop sets in config

[timkelty]

With a config like…

        gradients: theme => ({
            teal: [
                theme('colors.teal.300'),
                theme('colors.teal.200'),
            ],
            sherbet: [
                theme('colors.teal.300'),
                theme('colors.rose.300'),
                theme('colors.orange.300'),
            ]
        }),

The following plugin will add .bg-gradient-${name} classes.

        plugin(function({ addUtilities, e, theme, variants }) {
            const gradients = theme('gradients', {})
            const gradientVariants = variants('gradients', [])
            const utilities = Object.entries(gradients).map(([name, stops]) => ({
                [`.${e(`bg-gradient-${name}`)}`]: {
                    '--gradient-color-stops': stops.join(',')
                }
            }));

            addUtilities(utilities, gradientVariants);
        }),

This seems like a sensible addition to include in core?
A breaking way to do this could be:

gradientColorStops: theme => ({
  colors: ...theme('theme'),
  stops: {
            sherbet: [
                theme('colors.teal.300'),
                theme('colors.rose.300'),
                theme('colors.orange.300'),
            ]
  }
})

…or to be non-breaking, you could test the value for an array?

If either approach sounds agreeable, I'm happy to PR.

[simonswiss]

Hey! Thanks for sharing this 👍

You can make the examples you've shared here with the existing gradient utilities, out of the box:

<div class="bg-gradient-to-r from-teal-200 to-teal-300"></div>

<div class="bg-gradient-to-r from-teal-300 via-rose-300 to-orange-300"></div>

Your implementation is definitely a good idea for a plugin, particularly if you want to build more complex gradients, but, I am not sure this should live in core.

I might be missing a point, so.. do you have a strong argument for why it should make its way to core?

[timkelty]

@simonswiss Yeah…after second thought, I think you're right.

My reasoning was since those are "brand gradients", they felt like they should be isolated and part of the config.
However, like everything else in Tailwind, this abstraction is probably best done at the template/view level and call it a day.

<div class="{{ tailwind.gradients.sherbet }}"></div>

Thanks for the gut check!

Side note: for this same project, I ended up playing with https://github.com/cossssmin/tailwindcss-border-gradients for border-image gradients.

This got me thinking, the naming of gradientColorStops and from-, to-, via- is vague (perhaps intentionally), but currently only applicable to backgrounds.

I would consider either:

• renaming those things to be bg specific (backgroundGradientColorStops, bg-from-)
• or, plan on making them play nice together. The downside to the latter is you wouldn't ever be able to apply a different border gradient and a bg gradient to the same element because of the shared from-, etc.

[timkelty]

After some use, the only real use-case for having this in core is that for "prefab" gradients like this, there's no good way to pull them with @apply, short of making your own class (just like the plugin is doing).

Example:

From the template site, I can abstract that set of classes easily:

<div class="{{ tailwind.gradients.sherbet }}"></div>

But to be able to reuse on the css-side, the only real option is:

.bg-gradient-sherbet {
  @apply from-teal-300 via-rose-300 to-orange-300;
}
.prose a {
  @apply bg-gradient-to-r bg-gradient-sherbert;
}

Which is fine, but what I was trying to avoid.