100 lines
No EOL
8 KiB
JSON
100 lines
No EOL
8 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "44dcbb55-20f6-4737-9557-d6301fca587d"
|
|
}
|
|
],
|
|
"langcode": [
|
|
{
|
|
"value": "en"
|
|
}
|
|
],
|
|
"type": [
|
|
{
|
|
"target_id": "daily_email",
|
|
"target_type": "node_type",
|
|
"target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7"
|
|
}
|
|
],
|
|
"revision_timestamp": [
|
|
{
|
|
"value": "2025-05-11T09:00:55+00:00"
|
|
}
|
|
],
|
|
"revision_uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"revision_log": [],
|
|
"status": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"uid": [
|
|
{
|
|
"target_type": "user",
|
|
"target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849"
|
|
}
|
|
],
|
|
"title": [
|
|
{
|
|
"value": "Custom styles in Tailwind CSS: `@apply`, `theme` or custom plugins"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2022-09-11T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-05-11T09:00:55+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2022\/09\/11\/custom-styles-tailwind-css-apply-theme-custom-plugins",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>There are three ways to add custom styles to a Tailwind CSS project. As there have been <a href=\"https:\/\/twitter.com\/adamwathan\/status\/1559250403547652097\">some recent tweets<\/a> around one of them - the <code>@apply<\/code> directive - I'd like to look at and give examples for each.<\/p>\n\n<h2 id=\"what-is-%60%40apply%60%3F\">What is <code>@apply<\/code>?<\/h2>\n\n<p><code>@apply<\/code> is a PostCSS directive, provided by Tailwind, to allow re-using it's classes - either when extracting components or overriding third-party styles.<\/p>\n\n<p>The CSS file is the same as if you were writing traditional CSS, but rather than adding declarations to a ruleset, you use the <code>@apply<\/code> directive and specify the Tailwind CSS class names that you want to apply.<\/p>\n\n<p>For example:<\/p>\n\n<pre><code class=\"css\">fieldset {\n @apply bg-primary-dark;\n}\n<\/code><\/pre>\n\n<p>This is a simple example but it's easy to see how this could be used in ways that weren't intended and how edge-cases can be found.<\/p>\n\n<p>Adam said in a another tweet:<\/p>\n\n<blockquote>\n <p>I estimate that we spend at least $10,000\/month trying to debug extremely edge-case issues people run into by using <code>@apply<\/code> in weird ways.<\/p>\n<\/blockquote>\n\n<h2 id=\"using-the-%60theme%60-function\">Using the <code>theme<\/code> function<\/h2>\n\n<p>As well as <code>@apply<\/code>, Tailwind also provides a <code>theme<\/code> function that you can use in your CSS file. This removes the abstraction of using the class names and adds the ability to retrieve values from the <code>theme<\/code> section of your tailwind.config.js file.<\/p>\n\n<pre><code class=\"css\">fieldset {\n backgroundColor: theme('colors.primary.dark');\n}\n<\/code><\/pre>\n\n<p>This seems to be the preferred approach over using <code>@apply<\/code>.<\/p>\n\n<h2 id=\"creating-a-custom-plugin\">Creating a custom plugin<\/h2>\n\n<p>The <code>theme<\/code> function is also available if you write a custom Tailwind CSS plugin:<\/p>\n\n<pre><code class=\"javascript\">const plugin = require('tailwindcss\/plugin')\n\nplugin(({ addBase, theme }) => {\n addBase({\n fieldset: {\n backgroundColor: theme('colors.primary.dark'),\n }\n })\n})\n<\/code><\/pre>\n\n<p>This is an approach that I've used for <a href=\"https:\/\/github.com\/opdavies?tab=repositories&q=%23tailwindcss-plugin\">generic, open-source plugins<\/a> but for project-specific styling, I've mostly used <code>@apply<\/code> or the <code>theme<\/code> function.<\/p>\n\n<p>That said, I like the modular architecture of having different custom plugins - especially if they're separated into their own files - and being able to easily toggle plugins by simply adding to or removing from the <code>plugins<\/code> array.<\/p>\n\n<p>I usually don't write many custom styles in a Tailwind project but I think that I'll focus on using the <code>theme<\/code> function going forward, either in a stylesheet or a custom plugin.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>There are three ways to add custom styles to a Tailwind CSS project. As there have been <a href=\"https:\/\/twitter.com\/adamwathan\/status\/1559250403547652097\">some recent tweets<\/a> around one of them - the <code>@apply<\/code> directive - I'd like to look at and give examples for each.<\/p>\n\n<h2 id=\"what-is-%60%40apply%60%3F\">What is <code>@apply<\/code>?<\/h2>\n\n<p><code>@apply<\/code> is a PostCSS directive, provided by Tailwind, to allow re-using it's classes - either when extracting components or overriding third-party styles.<\/p>\n\n<p>The CSS file is the same as if you were writing traditional CSS, but rather than adding declarations to a ruleset, you use the <code>@apply<\/code> directive and specify the Tailwind CSS class names that you want to apply.<\/p>\n\n<p>For example:<\/p>\n\n<pre><code class=\"css\">fieldset {\n @apply bg-primary-dark;\n}\n<\/code><\/pre>\n\n<p>This is a simple example but it's easy to see how this could be used in ways that weren't intended and how edge-cases can be found.<\/p>\n\n<p>Adam said in a another tweet:<\/p>\n\n<blockquote>\n <p>I estimate that we spend at least $10,000\/month trying to debug extremely edge-case issues people run into by using <code>@apply<\/code> in weird ways.<\/p>\n<\/blockquote>\n\n<h2 id=\"using-the-%60theme%60-function\">Using the <code>theme<\/code> function<\/h2>\n\n<p>As well as <code>@apply<\/code>, Tailwind also provides a <code>theme<\/code> function that you can use in your CSS file. This removes the abstraction of using the class names and adds the ability to retrieve values from the <code>theme<\/code> section of your tailwind.config.js file.<\/p>\n\n<pre><code class=\"css\">fieldset {\n backgroundColor: theme('colors.primary.dark');\n}\n<\/code><\/pre>\n\n<p>This seems to be the preferred approach over using <code>@apply<\/code>.<\/p>\n\n<h2 id=\"creating-a-custom-plugin\">Creating a custom plugin<\/h2>\n\n<p>The <code>theme<\/code> function is also available if you write a custom Tailwind CSS plugin:<\/p>\n\n<pre><code class=\"javascript\">const plugin = require('tailwindcss\/plugin')\n\nplugin(({ addBase, theme }) => {\n addBase({\n fieldset: {\n backgroundColor: theme('colors.primary.dark'),\n }\n })\n})\n<\/code><\/pre>\n\n<p>This is an approach that I've used for <a href=\"https:\/\/github.com\/opdavies?tab=repositories&q=%23tailwindcss-plugin\">generic, open-source plugins<\/a> but for project-specific styling, I've mostly used <code>@apply<\/code> or the <code>theme<\/code> function.<\/p>\n\n<p>That said, I like the modular architecture of having different custom plugins - especially if they're separated into their own files - and being able to easily toggle plugins by simply adding to or removing from the <code>plugins<\/code> array.<\/p>\n\n<p>I usually don't write many custom styles in a Tailwind project but I think that I'll focus on using the <code>theme<\/code> function going forward, either in a stylesheet or a custom plugin.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
],
|
|
"feeds_item": [
|
|
{
|
|
"imported": "2025-05-11T09:00:55+00:00",
|
|
"guid": null,
|
|
"hash": "6b48ac239501bd0ff52a0f5acaedb81c",
|
|
"target_type": "feeds_feed",
|
|
"target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
|
|
}
|
|
]
|
|
} |