So I want to make a TailWindCSS Super Config in which I have every height fraction up-to 12, same for height screen and font size, and a lot of colours.
I know that TailWindCSS gives a pretty good default config, but I want it bigger, better.
FileSize is not an issue for the CSS and it is going to be Purged, after working with PurgeCSS for a little while, I feel confident that it will only include what is needed.
Having a large StyleSheet does mean that some developers may take it too far and start to overuse classes, however I personally feel that this will not be an issue within my company, and I would still like to have a large config.
I want to automatically generate the config so that I can have the 1/2, 2/3, 5/5 etc generated without me having to enter them manually into the config, along with this I want every variant for every attribute, making the end CSS even bigger!
In Short, I would like a way to generate some of the config automatically, and I want to know the correct order to declare the config (EG: height, width, box shadow etc).
Thanks, Justin.
Everything that you mentioned you can do it easily with the default config file that TailwindCSS gives you
This is the beauty of TailwindCSS, easy configuration, unlimited choices
Try https://tailwindcss.com/docs/configuration
Example:
// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
'lollipop': {
100: '#FFFFEE',
200: '#FFFFD5',
300: '#FFFFBB',
400: '#FFFE88',
500: '#FFFE55',
600: '#E6E54D',
700: '#999833',
800: '#737226',
900: '#4D4C1A',
},
'lola': {
100: '#FCFBFC',
200: '#F8F4F7',
300: '#F4EDF1',
400: '#EBE0E7',
500: '#E3D3DD',
600: '#CCBEC7',
700: '#887F85',
800: '#665F63',
900: '#443F42',
}
},
spacing: {
'96': '24rem',
'128': '32rem',
'254': '64rem',
}
}
}
}
So, the result of my investigations is just to use the native ability of Javascript to generate parts of the config automatically, saving me time writing out config lines.
myVariants = {};
for(let x = 1; x < 12; x++)
myVariants[x + "/12"] = (8.33333 * x) + "%";
console.log(myVariants);
There is much more you can do to make your config even more automated too!
Related
I have an array of colors gray-200, red-200, blue-200, green-200 that I also need hover: and border- variants (e.g. hover:gray-200).
If I explicitly add a comment (/* ... */) explicating the exhaustive list of permutations (hover:gray-200, border-blue-200, etc.), the styles load properly. Presumably because of (purgeable html?), I can't just dynmically create these on the fly (when I do, the CSS doesn't load).
The inline comment feels like an understandable location, but not the ideal spot to put all that. Is there a "proper" place to do this (like in the config file or something), and if so, how/where?
Forgive the ignorance if this is obvious, I'm new to tailwind.
EDIT: If it matters, I'm using React and NodeJS and yarn.
As you mentioned you cannot build dynamic CSS classes on the fly. In order to work you need to mention somewhere in your app full class name or safelist it. It can be other file, comment or safelist section in Tailwind configuration file
Please note there are no such utility as hover:gray-200 etc as you need to be specific what do you colorize (like text - hover:text-gray-200, background - hover:bg-gray-200 etc)
1. Pass an array of strings
Every part will be compiled as it is
// tailwind.config.js
module.exports = {
safelist: [
'text-gray-200',
'bg-gray-200',
'border-gray-200',
'hover:text-gray-200',
'hover:bg-gray-200',
'hover:border-gray-200',
// ....
],
}
2. In a specific file
Common pattern to create and name file safelist.txt, put in a root of your project and watch its content. The content of the file could be any, extension could be any, name could be any, there are only two rules - it should contain full names of required classes (like in example 1) and this file should be included in content section
// tailwind.config.js
module.exports = {
content: [
// source files,
'./safelist.txt'
]
}
These both methods not ideal as you need to write a lot of classes on your own. However tailwind.config.js is still JS file so you can do something like this
3. Using mapping
Create an array of required color utilities and map them to generate required class names. This way it can be dynamic
// tailwind.config.js
const colors = ['gray-200', 'red-200']
const safelist = colors.map(color => `text-${color} bg-${color} border-${color} hover:text-${color} hover:bg-${color} hover:border-${color}`)
module.exports = {
safelist:,
}
Still not perfect - sometimes thing can be messy and hard to read but it is simple
4. Regular expressions
Finally Tailwind provides you a way to use patterns for safelisting
// tailwind.config.js
module.exports = {
// an array of multiple patterns
safelist: [
{
pattern: /(bg|text|border)-(red|gray)-200/,
variants: ['hover'],
},
],
}
Here we're saying safelist combination of background, color, border-color properties with red-200 and grey-200 utilities plus hover variant for all of them. Variants could be any, if you need you should pass breakpoint variants also and combination of them. Take a look
// tailwind.config.js
module.exports = {
// just as example you can specify multiple patterns for each utility/variant combination
safelist: [
{
pattern: /(bg|text)-(red|gray)-200/,
variants: ['hover'],
},
{
pattern: /border-(red|gray)-500/, // another color
variants: ['hover', 'lg', 'lg:hover']
}
],
}
One last thing about safelisting colors - if you left pattern like this /(bg|text|border)-(red|gray)-200/ it would safelist all color utilities opacity included (bg-gray-200/0, bg-gray-200/5, bg-gray-200/10 and so on).
/** part of compiled CSS file */
.border-gray-200 {
--tw-border-opacity: 1;
border-color: rgb(229 231 235 / var(--tw-border-opacity))
}
.border-red-200 {
--tw-border-opacity: 1;
border-color: rgb(254 202 202 / var(--tw-border-opacity))
}
.border-gray-200\/0 {
border-color: rgb(229 231 235 / 0)
}
.border-gray-200\/5 {
border-color: rgb(229 231 235 / 0.05)
}
/** and so on - many-many classes */
If you are planning not to use opacity variants, finish your pattern with $ dollar sign
// tailwind.config.js
module.exports = {
// an array of multiple patterns
safelist: [
{
pattern: /(bg|text|border)-(red|gray)-200$/, // here is $ - no opacity utilities
variants: ['hover'],
},
],
}
Here - check different types of safelist config and Generated CSS (tab at the bottom - it will show all compiled classes)
DaisyUI has default themes and you can change them with the data-theme attribute e.g. <html data-theme="cupcake">. It seems as though the default is the light theme.
The problem is that I want to be able to use the #apply directive with DaisyUI so that I can have BEM class names in the template and DaisyUI utility classes in the style block. It seems that I can't set a default that will be picked up at compile time.
In my tailwind.config I've tried using the light theme to see if I could overwrite it, e.g.:
plugins: [require('daisyui')],
daisyui: {
themes: [
{
light: {
primary: '#EF3054',
secondary: '#C67F43',
accent: '#43AA8B',
neutral: '#FBF5F3',
base100: '#FFFFFF',
info: '#3ABFF8',
success: '#36D399',
warning: '#FBBD23',
error: '#F87272',
},
},
],
}
But this doesn't work. I've tried looking into the library itself for clues into how I could overwrite the default theme at compile time but I can't see how.
Although some people consider BEM with Tailwind an anti-pattern, I had long held this view myself as well, I have since changed my mind and feel that the extra effort does help disambiguate your template with the added benefit of allowing bespoke CSS whenever you need to drop into it so please don't suggest just using the inline utility classes as I know this works.
I'm not sure what is your issue exactly.
But once you changed tailwind config, then it should work.
If you want to change your default theme with another one, it requires some code.
But now you changed your light theme, so it will directly work.
Please check your content property again. I'm working on Next JS.
And I think base100 property should be base-100.
module.exports = {
content: [
"./pages/**/*.{js,ts,jsx,tsx}",
"./components/**/*.{js,ts,jsx,tsx}",
],
...
daisyui: {
themes: [
{
light: {
...require("daisyui/src/colors/themes")["[data-theme=light]"],
primary: '#EF3054',
secondary: '#C67F43',
accent: '#43AA8B',
neutral: '#FBF5F3',
"base-100": '#FFFFFF',
info: '#3ABFF8',
success: '#36D399',
warning: '#FBBD23',
error: '#F87272',
},
},
],
}
...
In an attempt to update PHP version, I came up with some funky node issues oddly enough instead. I'm having some weird Tailwind 3.0 compiling issues where not all the color shades are appearing. The defaultTheme colors are not compiling right. I have colors in the tailwind-config.js but not all shades are appearing like the 700 for blue. I noticed if I put the colors I want in the array (view gray in the example attached), it works. Do I have to add every color shade? This suddenly just started happening. It was fine before the PHP update. I'm trying to use text-blue-700 and it can't find it.
Example of the setup: https://play.tailwindcss.com/HSzmza7os3?file=config
Has anyone else had this issue before where the defaultTheme won't pull in all the theme color shades?
You don't have to use defaultTheme if you're trying to add variations to the existing theme. Instead, you can put your color additions in the extend section of the config object. For example, to keep the default Tailwind classes like text-gray-500 and add your new ones:
module.exports = {
plugins: [],
theme: {
extend: {
colors: {
gray: {
lightest: '#F7F7F7',
lighter: '#f1f1f1',
light: '#e1e1e1',
default: '#57677A',
dark: '#C2CAD3',
darker: '#656565',
darkest: '#808080',
},
},
},
},
}
If you only want to use the default colors (no additions), you should not have to add anything to the config.
Working version of your example: https://play.tailwindcss.com/rKi0lRmivh
Default is 150ms, was looking to extend this to 250ms as an application default.
Tried everything I could think of, last attempt being
transitionDuration: {
DEFAULT: '250ms'
},
in tailwind.config.js under theme, theme.extend, variants, and variants.extend.
Any help would be appreciated!
theme: {
transitionDuration: {
DEFAULT: '250ms'
}
}
in your tailwind.config.js should work.
Demo: https://play.tailwindcss.com/zSWIMghZQf
(Default transition duration overwritten to 2000ms.)
For reference: With npx tailwindcss init --full you can create a configuration file that contains all tailwind default values.
Just like ptts answered before me, inserting an override in the theme section of your tailwind.config.js will do the trick.
What I'd like to add is that the new value for transitionDuration will completely replace Tailwind’s default configuration for that key, and the initial transition duration utilities will not be generated. So if you only define DEFAULT under the transitionDuration key, your classes like .duration-500 will not work.
The solution is to define the full set of duration values you might use. For your convenience, here's the full set from the default theme:
transitionDuration: {
DEFAULT: '150ms',
75: '75ms',
100: '100ms',
150: '150ms',
200: '200ms',
300: '300ms',
500: '500ms',
700: '700ms',
1000: '1000ms',
},
If you want to update the DEFAULT while still retaining all of the other durations, use something like:
transitionDuration: {
DEFAULT: '500ms',
75: '75ms',
100: '100ms',
150: '150ms',
200: '200ms',
300: '300ms',
500: '500ms',
700: '700ms',
1000: '1000ms',
},
I'm developing a new tab replacement extension for Google Chrome and I'd like to allow the user to customize the background, to do so I'm using the storage.sync API as suggested by this page.
The problem is that the style changes are applied asynchronously, so the default background (white) is briefly used during the page load resulting in unpleasing flashes.
Possible (unsatisfying) solutions are:
do not allow to change the background;
hard code a black background in the CSS (and move the problem to custom light backgrounds);
use a CSS transition (still super-ugly).
What could be an alternative approach?
Follows a minimal example.
manifest.json
{
"manifest_version": 2,
"name": "Dummy",
"version": "0.1.0",
"chrome_url_overrides": {
"newtab": "newtab.html"
},
"permissions": [
"storage"
]
}
newtab.html
<script src="/newtab.js"></script>
newtab.js
chrome.storage.sync.get({background: 'black'}, ({background}) => {
document.body.style.background = background;
});
I come up with a reasonable solution. Basically since the localStorage API is synchronous we can use it as a cache for storage.sync.
Something like this:
newtab.js
// use the value from cache
document.body.style.background = localStorage.getItem('background') || 'black';
// update the cache if the value changes from the outside (will be used the next time)
chrome.storage.sync.get({background: 'black'}, ({background}) => {
localStorage.setItem('background', background);
});
// this represents the user changing the option
function setBackground(background) {
// save to storage.sync
chrome.storage.sync.set({background}, () => {
// TODO handle error
// update the cache
localStorage.setItem('background', background);
});
}
This doesn't work 100% of the times but neither do the simple:
document.body.style.background = 'black';
So it's good enough.¹
¹ In the real extension I change the CSS variables directly and I obtain much better results than setting the element style.