DEV Community: codestruct.io

The power of CSS attribute selectors

codestruct.io — Tue, 30 Nov 2021 15:19:31 +0000

Besides the obvious utility of selecting elements with an exactly matching data attribute, there are a lot more things we can achieve with CSS attribute selectors.
In general, the attribute selector can target any attribute that's attached to an HTML element. By default, the selector is case sensitive and has a lower specificity than id's and classes.

Here's an attribute selector in its simplest form, selecting every anchor element that has an href attribute — regardless of the actual href URL:

a[href] {
    /* ... */
}

If we want it to be more specific about which href to target, we can explicitly pass the URL to the attribute selector like this

a[href="https://specific-url.com"] {
    /* ... */
}

One of the latest specs changes introduced a new flag for attribute selectors, which allows us to make the matching case insensitive, by adding an i after our selector. This is fairly well supported and works across all modern browsers, except IE11.

a[href="https://specific-url.com" i] {
    /* matches <a href="https://SpEciFic-url.com"></a> ... */
}

Special types of attribute selectors

Besides matching an attribute with an existing attribute or a specific value, we can use other types of attribute selectors to achieve partial matching on the
value of an attribute. These selectors can also be combined to match very specific elements.

CSS attribute contains

Using the wildcard operator * we can match any element that has an attribute containing the given string in any form.
That means the example below would match the exact string value but also something value something as well as somethingvaluesomething.

[data-attribute*="value"] {
  /* ... */
}

CSS attribute starts with

If we want to look for an attribute whose value starts with a given string, we can use the ^ operator lie below.
In that case, we'd only match value something and valuesomething but not something value.

[data-attribute^="value"] {
  /* ... */
}

CSS attribute ends with

Conversely to looking for matched at the start, we can also look at the very end of an attribute's value by useing the $ operator.
We'd match something value but not value something. This is especially interesting because we know that files always have a certain extension and by passing
the full name into a data-attribute, we'd be able to match elemenets that represent PDF documents like this a[href$="pdf"].

[data-attribute$="value"] {
  /* ... */
}

CSS attribute is in space-separated or dash-separated lists

There are two selectors that allow us to specifically look for matches inside lists, where one is only matching when the value is dash-separated | and the other operator
matches everything inside a space-separated list ~. Especially the space separation can also be achieved with other operators mentioned above.


[data-attribute~="value"] {
  /* matches eg. <li data-years="thor value loki">...</li> */
}

[data-attribute|="value"] {
  /* matches eg. <li data-years="value-2021">...</li> */
}

Combining attribute selectors

Of course, we can also use multiple attribute selectors simultaneously to select specific elements. This can be especially handy when the HTML
provides us with enough info to create different styles only through our attributes. Let's say we want to give icons to every file download link
on a site and a special icon to PDFs. We can combine the contains and ends with selectors to select all files and then specifically find all PDFs.

a[href*="/downloads"] {
    /* file is in /downloads directory */
}

a[href*="/downloads"][href$="pdf"] {
    /* file is in /downloads directory */
    /* AND ends with pdf */
}

Negating the attribute selector with :not

All the attribute selectors above can also be combined with the CSS :not selector, so we could also take our example above and find all files
that are inside the downloads directory but are specifically not PDF files.

a[href*="/downloads"]:not([href$="pdf"]) {
    /* file is in /downloads directory */
    /* AND ends NOT with pdf */
}

Using attribute selectors in Javascript

Just like using regular class and id selectors, we can also utilize all of the above selectors when writing JavaScript to select DOM elements.

let team = document.querySelector('img[src*="team"]');

A brief introduction to Remix JS

codestruct.io — Tue, 23 Nov 2021 15:03:47 +0000

Remix is a new full stack JavaScript framework that gets rid of static site generation and also in other areas, does a few things differently than what we're used to from other frameworks. It relies on React to render the UI and if you're familiar with Next.js you can certainly spot a lot of similarities. However, there are also clear distinctions, like nested routes, handling of data fetching and data saving as well as error handling. Let's take a look at those concepts and how they compare to other techniques, currently used in popular frameworks.

Application structure and routes

The easiest way to get started with a new Remix project is by installing it through npx and following the interactive prompts:

npx create-remix@latest

Once we're done with that, our project's structure is already set up for us and we're good to go. If we compare Remix to Next.js, we'll see that with Remix we're also
writing client side and server ide code inside our route files. However, Remix gives us a little more control to fine-tune things like caching and this also shows in having two separate files for handling requests — entry.client and entry.server that represent our entry points and therefore determine what's run first on the server and client respectively. We also get a root.tsx which holds the root component to our app and renders the <html>, first <meta> tags, and so on.

├── ...
├── app
│   ├── entry.client.tsx
│   ├── entry.server.tsx
│   ├── root.tsx
│   ├── routes
│   │   └── index.tsx
│   ├── styles
│   │   └── global.css
│   └── utils.server.tsx
├── jsconfig.json
├── package.json
├── public
├── remix.config.js

We also see a framework-specific remix.config.js which allows to to configure a lot off different details about oour application, such as the default public directory, development ports and much more.

Nested routing

A very neat mechanism in Remix is the ability to render parts of a page based on the route we're on. When thinking of other frameworks, this would come down to either a separate route with its own index file or specifically matching a route to one or more components. We're used to binding parts of our URL to different routes or components already — the way Remix does it, is best described as nested layouts, where each part of the URL is by definition bound to a route file. Here's an example from their official site.

The route shown above (/sales/invoices) would therefore be represented by three files

routes/sales.jsx
routes/sales/index.jsx
routes/sales/invoices.jsx

Our first file is the wrapper that gets called first and based on the rest of the URL decides which "sub-components" should be rendered. The initial state
would be routes/sales/index.jsx and when navigating to /invoices, our wrapper pulls in the code from routes/sales/invoices.jsx. The way this is realized in code is not through regular components, but through an <Outlet /> which is part of react-router-dom and allows for this mapping of nested layouts to routes (route components) rather than regular components.

Under the hood this allows Remix to preload the different parts on a page, which makes it really fast and lets us eliminate loading states as much as possible. There are probably some more interesting things we can do here that I haven't fully explored yet.

Styling pages and components

Styling components is fairly straightforward with Remix, because it's very close to how it works on the web since forever. Remix brings its own LinksFunction which can be used to import CSS files on a per-route basis. That's also where we have to be a little careful and separate our CSS into global CSS that should be available to every route and specific CSS that will not be loaded outside a certain route at all.

import stylesUrl from "../styles/index.css";

export let links: LinksFunction = () => {
  return [{ rel: "stylesheet", href: stylesUrl }];
};

export default function IndexRoute() {
  return <div>Index Route</div>;
}

Once again Remix relies heavily on how the web already works, so if we wanted to use preprocessors or frameworks like Tailwind, we'd want to pass the compiled resources paths to Remix, just like we would with vanilla CSS files.

Loading data

To get data inside a route component in Remix, we can use a loader, which is just an async function that returns the requested data. Inside our components, we can then access it through a hook called useLoaderData.

import { useLoaderData } from "remix";

export let loader = async () => {
  return getData(); // does the heavy lifting, DB calls etc. and returns data
}

// Component function starts here
export default function Component() {
    let allData = useLoaderData(); // data is now available inside our component
}

Note that the function is always called loader by convention and is only executed server-side, which means we also have access to all node features and libraries to connect to databases and fetch data, like we're used to on the server.

If we're passing parameters to our routes, like a dynamic URL often times requires, the loader also has access to that, by passing in the request parameters like this

export let loader = async ({ params }) => {
    return params.slug
}

Storing data

If we want to send new user-generated data back to the backend, to save it to a database for example, Remix lets us use so-called actions. Actions rely on forms for the actual data input and are also only executed server-side, despite being in your route file.
The functions are — again by convention — called action and can also trigger (return) a redirect. Let's look at an example.

export let action = async ({ request }) => {
  let formData = await request.formData()
  let title = formData.get("title")
  let slug = formData.get("slug")

  await createPost({ title, slug }) // actual call to store data...

  return redirect("/home")
}

export default function NewPost() {
  return (
    <Form method="post">
      <p>
        <label>Post Title: <input type="text" name="title" /></label>
      </p>
      <p>
        <label>Post Slug: <input type="text" name="slug" /></label>
      </p>
      <button type="submit">Create Post</button>
    </Form>
  );

We see that the action function takes the request as a parameter and thereby has access to everything our form sends over to the server. From there we're free to use any node code to store our data.

Handling errors

The way Remix handles errors is quite unique, as it allows us to create ErrorBoundarys that will be shown in case something with our route components didn't work as expected and an error is thrown. That way, if we're using Remix's nested routes, we might see a single throwing
and error, but not necessarily the whole page. The smart thing about error boundaries is that they bubble up (the routes) to the closest error boundary. So the easiest case would be having one error boundary at the root level, comparable to a full 404. However, the image below nicely
demonstrates how having multiple small error boundaries (one per route component for examaple) can leave the rest of an application intact.

export function ErrorBoundary({ error }) {
  return (
    <html>
      <head>
        <title>Something went wrong!</title>
        <Meta />
        <Links />
      </head>
      <body>
        ... anything we want to let the user know goes here
      </body>
    </html>
  );
}

Implementing an error boundary is as simple as adding an ErrorBoundary function to our route components as shown above.

How to write a custom event system in JavaScript

codestruct.io — Fri, 19 Nov 2021 07:18:01 +0000

When building complex applications it's always a good idea to take a step back and think through architectural choices from the get-go. One pattern that really forces us to do that is an event system or the closely related PubSub pattern, which we'll take a closer look at in this article.

The biggest advantage of this pattern is that we get to decouple parts of our application and have them talk to each other through a middleman, or in simpler cases, we just broadcast an event and have a listener that executes when the event is triggered. A big advantage of this pattern is that all our events get routed through the same logic before being picked up by the listeners, which allows us to do some extra work and extend all events in our system later on.

Let's clear up some terms before we move into code. Given a simple example like on-page notifications, our core functionality that will be executed can be a simple alert() . Now to not call it directly but actually use an event system, we need to implement an Observer that will listen to incoming events, delegate our invocation and call all the right functions for us.

const Observer = function() {
    var self = this
    self.events = {}

    return {

        dispatch: function(eventName) {
            // We already know we want to be able to call our observer and
            // it will need to dispatch the actual event
        },

        on: function(eventName, callback) {
            // Our observer will need to be able to listen itself for incoming events
            // that we'll notify the listeners about (via callbacks)
        }

    };

}();

This Observer pattern above will be our middleman and listen to events when we define them in like this: Observer.on('eventName', callback). At the same time, it allows us to trigger those events via Observer.dispatch('eventName') whenever we want the receivers to be notified. The most important part inside our observer is the events object that will hold all callbacks in the form of {[eventName: callback()]}. Let's go ahead and fill the functions with code to see how the Observer pattern works in action.

Implementing the observer pattern

const Observer = function() {
    var self = this
    self.events = {}

    return {

        dispatch: function(eventName) {
            var events = self.events[eventName]
            events.forEach((callback) => callback())
        },

        on: function(eventName, callback) {
            if (typeof self.events[eventName] === 'undefined') {
                self.events[eventName] = []
            }

            self.events[eventName].push(callback)
        }

    }
}()

The on method is used to register our events and we need to call it before we can actually dispatch an event. it takes an event name and a callback as parameters and pushes both into our events object as described above.

Our dispatch function that will be triggered to fire off an event, takes an event name as the only argument. In fact, this should be the same event name that we previously added to the events object when we registered the event with our on function.

And with that, we have a working event system that can be used like this:

// Listen to an event
Observer.on('testevent', function() {
    console.log('This will be executed when our event fires')
})

// Fire our event
Observer.dispatch('testevent')

Keep in mind that this is a very minimal custom event system and there are more mature systems out there. If we were to expand this minimal example, we'd need to take proper care of error handling, unbinding events (off function to our on), and implement some general checks around passed arguments.

If you want to dive deeper into the observer pattern or Pub Sub, here's a great resource for further reading with implementation details: https://addyosmani.com/resources/essentialjsdesignpatterns/book/#mediatorpatternjavascript

A nifty alternative to box-shadows

codestruct.io — Wed, 07 Jul 2021 12:56:06 +0000

Most folks know about the box-shadow property and use it a lot already in their CSS, however there are certain scenarios where a box-shadow doesn't give us ideal results. There is however also a CSS filter called drop-shadow that let's us do some cool things we cannot achieve with box-shadows. It's currently supported in all modern browsers and definitely worth a look. Here's how a drop-shadow looks like in CSS:



.selector {
  filter: drop-shadow(0 10px 12px rgba(0, 0, 0, 0.4));
}

What's the use case?

While box-shadows are sufficient in most scenarios, they can only give us a shadow around the exact shape of an element, which is usually angular or round due to a border-radius. With drop-shadows however, we can cast a shadow around elements and even images that stays in direct proximity to the non-transparent parts of the image or element.

So in essence this works on regular HTML elements, SVGs and also transparent PNGs. Here's an example:



.triangle {
    width: 180px;
    height: 180px;
    background: linear-gradient(45deg, yellow 50%, transparent 50%);
    filter: drop-shadow(0.2rem 0.2rem 1rem rgba(0,0,0, 0.8));
}

One downside we can spot in the syntax here is that we're not able to set a spread parameter the shadow should have. Other than that, the parameters match what we're used to with box-shadows (x-offset, y-offset, blur, color).

The real magic however becomes more obvious when we apply a drop-shadow to a transparent PNG, which gives us the same effect as seen above, instead of just putting a shadow on the whole image or container, we see the shadow aligned to the filled lines and shapes.



<style>
    img {
        filter: drop-shadow(0.5rem 0.5rem 0.5rem rgba(0, 100, 200, 0.7));
    }
</style>
<img src="./waves.png">

Stay tuned for more frontend-focused articles like this 👉 https://allround.io

Writing reusable modules in JavaScript

codestruct.io — Wed, 09 Jun 2021 07:02:15 +0000

As developers we often use a lot of libraries and packages and know very well how to use them. We're used to it, because packages and libraries are a huge part of the ecosystem and a great way to speed up development and free us from rather complicated, repetitive tasks.

When it comes to writing libraries or reusable modules from scratch however, it's not always so clear where to start and how to make sure our libraries are not breaking anything else in an application. Making sure we're using our own scope, function names and such are only part of what makes a good module. Let's take a close look at how to write our own libraries that can be plugged into different projects without worrying about breaking any existing code.

When we're the developer who's using a library, we care about simplicity and ideally want to understand what's going on by the name of the function we're calling alone. We're also very used to a certain kind of syntax, which probably looks something like this:

Library.init({
    option: "option"
})

Library.doThing(arg1, arg2);

We can initialize our library with some options and then just call pre-defined and hopefully well documented functions on the library, possibly passing in some arguments. Sometimes we'll get a return value or promise out of that function call, other times there might be a change in the DOM as a result of calling the function. Either way, we're very used to that kind of syntax when using libraries and so when writing our own we should try to imitate that.

The object literal notation in JavaScript lets us do just that. It also has the added benefit of keeping everything inside our object and therefore we're not putting anything related to our module on the global scope, except the object itself.

var Module = {
    // Our Object literal can hold simple variables
  someProperty: "someValue",

    // We can also declare further objects inside our object
  config: {
    reload: true,
    language: "en"
  },

    // And of course declare regular, named functions
  saySomething: function (word) {
    console.log(word);
  }
};

Module.say("hi");

The module pattern

We can take the object literal approach one step further with the module pattern, which allows us to declare public and private functions and variables, using closures. We're basically defining a public API that our library/module exposes, while keeping other internal states, variables and functions private and thereby inaccessible from the outside.

var Module = (function() {

  let secret = 0;
    let publicNumber = 2;

  function privateFunc(a) {
    console.log(a);
  }

    function addOne(b) {
        return b + 1;
    }

  return {
        addOne: addOne,
        publicNumber: publicNumber
  }

})()

Module.addOne(Module.publicNumber);

As shown above we can now explicitly define what functions and variables should be accessible from the outside by returning an object with only those things what we want the outside to know about. This is great, because we can hide away a lot of the heavy lifting or things we don't want to expose because calling them directly would break things. We're basically exposing a little API that is consistent and well structured.

While this pattern is great for frontend libraries and modules, it is also super convenient when writing modules in node. In fact most modules naturally follow this pattern in a way, because they have a (default) export statement. Here's how we can utilize the same structure in node

import db from '../models/index.js'

const MessageController = {
    sendMessage: async function(message) {
                // ...
        }

    receiveMessage: async function(message) {
        // ...
    },
}

export default MessageController

That way we get to keep the clean structure of our object literal / module pattern, while being able to just import our module like we would with other modules. We also get to chosse what to export explicitly while we can keep other functions private. Here's how we'd import the above module in node:

import MessageController from './controllers/message-controller.js';

Stay tuned for a look at other useful JS design patterns like singletons or the factories 👉 https://allround.io

Better CSS box shadows

codestruct.io — Mon, 03 May 2021 10:01:35 +0000

Using shadows is a great way to avoid clunky borders in otherwise light layouts and they've long surpassed being "just for decoration" elements in websites and apps alike. Especially when creating different levels of elevation that make some elements appear closer to the user than others – like a stack of elements – the use of shadows can make a big difference.

In general the closer something is to the user, the more attention it will get, just like the closest car in traffic (like buttons)
Smaller shadows that are closer to the elemet are great for capturing attention, while more diffuse and wide shadows are better suited to separate an element form its surrounding (like overlays)
Inset shadows can help create a feeling of plasticity or let elements appear bend inwards

To make a layout with shadows as consistent as possible, we should make sure to pick an imaginary lighting position and stick to it whenever using shadows. Otherwise we risk inconsistencies that look weird to users. Elements casting shadows in different directions also make it harder for the eye to quickly see a hierarchy when it comes to eleviation (z-index).

While those general guidelines are a solid start, the real magic of box shadows reveals itself when we use multiple shadows on the same element. In CSS a regular box shadow has the following properties:

box-shadow: x-offset y-offset blur-radius spread-radius color;

We can however add more shadows on the same element by comma-separating them:

div {
    box-shadow: 0 4px 6px rgba(0,0,0,0.7),
    0 5px 15px rgba(0,0,0,0.2);
}

The first shadow in this example is a box-shadow how it is often used, generally darker, close to the element and rather sharp with only a bit of blur – the classic way of using box-shadows.
The second shadow however has a bigger blur, a higher vertical offset and is rather subtle, giving the element a lot more depth, making it look closer to how we see shadows on objects in real life. If we wanted to achieve a perceived higher elevation that shadow would have to be more subtle the closer it gets and more intense the further "down" it is supposed to be.

While that's already a great improvement over simple box-shadows, we can go even further and create a fake plasticity by adding another shadow to the element. One brand that has incorporated this kind of plasticity into their overall appearance is Algolia. Here's a typical button, which adds a third (inset) shadow to the element, giving it a little edge on the bottom.

.btn {
    box-shadow: 0px 2px 4px rgb(45 35 66 / 40%), /* diffuse shadow behind the button */
    0px 7px 13px -3px rgb(45 35 66 / 30%), /* shadow offset to the bottom for depth */
    inset 0px -3px 0px #d6d6e7; /* boottom "edge" of the button */
}

Of course we don't always want to make use of every technique just because we can. When shadows are part of the layout however, it is definitely worth spending a bit of time on nailing those basics to get a clean and consistent look.

Customizing Tailwind CSS

codestruct.io — Wed, 21 Apr 2021 13:28:04 +0000

Just like in the golden days of Bootstrap, popular CSS frameworks like Tailwind involve the danger of many websites looking very similar. Especially with the UI components released as Tailwind UI it is super easy to get going with a beautiful default for almost every part of a website or application. Don't get me wrong, those are beautiful components throughout and using them to get something up quickly makes a lot of sense. The downside however is that your sites and applications will look very generic and close to others on the web, which means you're missing the chance to leave a lasting impression with you design and gain some brand awareness that a unique design can give.

The irony is, Tailwind is really well suited as a base UI system which is also fairly easy to customize and make your own. A lot of times people are underestimating the benefits of unique designs and put the customization somewhere in their backlog of things to do later. Let's change that! Let's take a look at how we can make Tailwind look different while keeping all the underlying goodies.

If you've never worked with Tailwind CSS or utility classes before, there's an introduction article I wrote over here. If you're already familiar with Tailwind, great! Let's dive right in!

Getting started

To get started, let's set up a very basic project that consist of nothing but bare HTML / CSS and JavaScript. Setting up Tailwind with Frameworks like Vue, Laravel and others might vary, because there are better ways of integrating it into the existing build steps. It's worth checking out the official documentation, to get instructions on how to do that – it's pretty good.

We'll keep it simple and start by creating the bare minimum we need from the terminal.

# Create our main HTML and CSS files as well as a bare PostCSS config file
touch index.html main.css postcss.config.js

# Initialize project with npm
npm init -y

# Install tailwind with PostCSS, autoprefixer and PostCSS CLI
npm install -D tailwindcss@latest postcss@latest postcss-cli autoprefixer@latest

# Create a minimal Tailwind config file
npx tailwindcss init

Next, we need to add the following base config to the PostCSS configuration file we just created, so it knows what to do when compiling our CSS. In general Tailwind is a PostCSS plugin and you can absolutely use it with other preprocessors too.

// postcss.config.js
module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  }
}

Finally we want to create an npm script that allows us to compile everything together by typing a single command. This is our build step for this tutorial and as mentioned above, when integrating Tailwind in different frameworks this might look different for you.

// package.json — to compile, run:
// $ npm run compile
"scripts": {
    "compile": "postcss main.css -o compiled.css"
}

Great! Now we just need to make sure we include the compiled.css in our HTML file and that's all we need in terms of boilerplate. Time to start the actual customization.

When it comes to styling the base theme and changing defaults like colors, margins, border radius, fonts and such there is a single file we can use to customize all of that, and that's the tailwind.config.js that was just created automatically in our setup step above. By default, it looks like this:

module.exports = {
  purge: [],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

And if you're wondering why it's empty and where the actual default theme is coming from, or just want to dig a little deeper into the defaults, here is a link to the defaults that get applied if we don't customize anything. However, that's exactly what we're here for – customizing. So let's start doing that by adding our own brand color:

module.exports = {
  purge: [],
  theme: {
    extend: {
      colors: {
        primary: {
          light: '#FFF538',
            DEFAULT: '#FFC233',
            dark: '#C19A32',
        },
      },
    },
  },
  variants: {},
  plugins: [],
}

In order to be able to use this new color class in our HTML, we'll have to run our build step once, by calling our PostCSS compiler from the terminal, like we defined above:

$ npm run compile

Sweet, we now have a new class at our fingertips called primary which we can use with all the prefixes and modifiers we defined above (light / dark). Let's try it out and see it in action, by applying the new class to a button element and making the button darker on hover:

<!-- In our index.html -->
<button class="btn bg-primary hover:bg-primary-dark transition p-4 my-4">
    I'm a button
</button>

Looking at spacing and breakpoints

Another important aspect of every layout that we might need to modify or extend, depending on what we want to create are spacings and breakpoints. Luckily for us, creating them is not a whole lot harder than adding our own custom colors, like we just did above. There is a gotcha when it comes to breakpoints however, as they need to be declared in the right order. Let's put it all together and jump into the details:

// Let's see why we need this in a second!
const defaultTheme = require("tailwindcss/defaultTheme");

module.exports = {
    purge: [],
    theme: {
        extend: {
            colors: {
                primary: {
                    light: "#FFF538",
                    DEFAULT: "#FFC233",
                    dark: "#C19A32",
                },
            },
            // Here we're adding a new breakpoint class
            screens: {
                xs: "475px",
                ...defaultTheme.screens,
                laaarge: "1600px",
            },
                        // Here we're declaring our new spacing classes
            spacing: {
                "small-bear": "2rem",
                "mama-bear": "15rem",
                "papa-bear": "30rem",
            },
        },
    },
    variants: {},
    plugins: [],
};

So just to recap what we just added: there's a new require statement at the top and two new blocks for the spacing and breakpoints (screens). Let's look at the spacings first, because they're rather similar to the color classes we defined earlier. In fact, they work just like our colors, except they don't take any modifiers like light – because we don't need that for our spacings. So with those newly defined spacings, we can now add big margins, paddings etc. to our layout. By using the class m-mama-bear for example, we'd add a margin of 15rem to all sides.

When it comes to breakpoints there's a small caveat when creating our own ones, because just like in regular CSS (when writing media queries) the order matters. That same principle applies to Tailwind breakpoints: If we want to declare a breakpoint that is smaller than the default ones, which start at sm 640px, we have to make sure to declare it before the default breakpoints. That's why in the example above, we're using the require statement at the top to grab all the default breakpoints and then when setting up our breakpoints, we're inserting them after our new xs. If we don't do that, our breakpoint will get overwritten just like media queries would be in a regular CSS file. Order matters!

Applying and extending base styles

So besides creating our own utility classes, we want to take a look at extending the Tailwind base styles. Because Tailwind does a full reset, you can quickly see that a regular h1 for example doesn't look much like a headline anymore, unless you start applying classes. That's by design and actually gives us a lot of flexibility. When we design complex components however, we might want to have base elements styled a certain way, even without applying a whole lot of classes. A good way of doing that is using the @apply rule. It allows us to apply a set of rules to a given CSS selector like this:

/* Require the basic Tailwind CSS */
@tailwind base;
@tailwind components;
@tailwind utilities;

h1 {
  @apply text-2xl; /* Applying our text-2xl rule on the h1 */
    @apply font-bold;
    @apply text-primary; /* We can even apply our custom classes! */

    font-family: monospace; /* And we can mix with regular CSS */
}

h2 {
  @apply text-xl;
}

Now without applying any classes directly in our HTML, we have added the predefined properties to our elements right in the CSS. That allows us to give every element a sane default without leaving our predefined system or repeating ourselves. This is great for more complex elements that require custom CSS or edge-cases where we don't want to make a whole new utility class, but just overwrite parts of our system.

Using and creating presets

Now that we've got a good first look at how to technically customize Tailwind, one more concept that is really worth knowing about is how to use presets. In fact the default styles Tailwind ships with are just a preset as well. If we want to keep a single source of truth for things like color, font and such and work on different projects for the same client, presets are super helpful. They allow us to use a single tailwind.config.js as the base and extend it, just like we just extended the default preset. So in fact, every config file is a preset itself. We can use other presets as the base for our project by stating it in our config file as follows:

// tailwind.config.js
module.exports = {
  presets: [
    require('./masters/tailwind-base.js')
  ],
  // ...
}

Because our presets variable is an array, you can already guess that we can also use multiple presets as our foundation and build on them. The important thing to keep in mind with the whole preset approach is that if there are overlapping rules defined, they will get overwritten in order you're requiring them — just like in regular CSS.

What's next?

There's still a lot we haven't covered yet, even though all of the above already sets us up with everything we need to really create fully custom layouts with Tailwind. If you want to dig deeper, I'd recommend looking into plugins and how to optimize Tailwind for use in production.

Here's a great article on creating a useful plugin

and the official documentation is a good starting point to learn more about optimizing for production.

Lastly, you can also grab the full source code of everything we just created above over on GitHub: https://github.com/allroundio/tailwind-example

An introduction to Tailwind CSS and utility classes

codestruct.io — Wed, 07 Apr 2021 14:18:35 +0000

If you haven't checked out Tailwind CSS yet or don't know what all the buzz regarding utility classes is all about, this article is for you. We'll take a first look at the advantages and get our hands just dirty enough to know what makes Tailwind a great CSS framework and what alternatives there are.

In general when talking about utility classes, you can think of primitive utilities that don't do much individually. In fact they shouldn't do much by themselves but work well when combined with other utility classes. The goal is to have a set of pre-existing classes that we can use to style HTML without writing a lot of custom CSS, which allows us to move faster and re-use those classes as much as possible.

Keeping it simple

We'll keep it simple and skip all the build-steps and setting up our tooling for now, even though it's an important and powerful part of Tailwind's magic. For now we'll just look at the concept of utility classes and see how they can help us reduce the required amount of custom CSS and allow us to style our content faster overall.

So instead of setting up a build step, we'll start by simply requiring the Tailwind stylesheet into a blank HTML file. That's all we really need to get going.

<link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" />

Let's start by looking at a <button> element and make it pretty! First, let's make sure it has a background-color —> In Tailwind we get a lot of predefined background colors, all created with rgba values, which allows our utility classes to change the colors based on the alpha, which we can set with a simple number in our class names like this:

<button class="bg-blue-700">I'm a button</button>

In this case, 700 sets the alpha and we can go lighter and darker from 50 to 900, where 50 is the only smaller step and the basic rule is that we can increase or decrease the alpha in hundreds. So if we wanted a lighter blue, we could set it to bg-blue-500. This is great, because it already gives us a clue how we can make use of this for our hover effect! Let's check that out.

In order to give our button a lighter blue on hover, we'll use one of Tailwind's prefixes: hover: and combine it with the background, we've just used above: hover:bg-blue-500

Sweet! We have a button that changes its background color on hover! Let's improve it further, by adding a font-color that is easier to read on our blue background. Just like we set the background-color, we can use the class text-<color> to set a color on our element. Again like the color palette for backgrounds, Tailwind comes with a set of predefined text-colors which can be adjusted by changing the alpha of the base color.

<button class="bg-blue-700 hover:bg-blue-500 text-white">I'm a button</button>

Side note: When using build tools we can also define our own colors, so we are not limited to the predefined palette.

That's a pretty rad button already and we were pretty fast to get there. This simple button element already illustrates how utility classes can save us a lot of time, as we have written exactly zero CSS so far, even though we changed the background color, text color and added a hover effect. And we're barely scratching the surface – let's dig a little deeper.

Digging a little deeper

I'm a sucker for details when it comes to user interactions, so I'm already having a hard time looking at the button we just created. It needs a transition! Luckily Tailwind has our back and we can make use of multiple transition properties, or go with the transition-all property, which defaults to the following.

transition-property: all;
transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1);
transition-duration: 150ms;

Making sure we adhere to best practices around the reduced-motion property, we can even use a prefix called motion-reduce: to only show the transition when reduced-motion is not activated. Let's put that together real quick:

<button class="bg-blue-700 hover:bg-blue-500 text-white transition-all motion-reduce:transition-none">I'm a button</button>

At this point you probably got the underlying idea of utility classes, utilizing a standardized way of naming with prefixes, the actual class and predefined and adaptable modifiers: {prefix}:{class}-{modifier}. One downside people complain about a lot with this expressive approach is that we're overloading our HTML that way and it actually becomes pretty unreadable. It's definitely a good idea to start formatting your HTML a little more according to that and let lines not run too long. The alternative however is probably a rather lengthy stylesheet, so there are always trade offs 🤷‍♂️

<div class="..."
   id="...">
  Heya!
</div>

Before wrapping up, let's take a look at the bigger picture of building sites with Tailwind: Layout, spacing and responsiveness. Tailwind comes with a ton of handy classes to support us in all those areas like floats, flexbox and positioning classes, allowing us to build more complex components and layouts quickly. Let's take a look at a classic horizontal navigation bar using flexbox and centering things inside.

<nav class="flex justify-between items-center px-16 bg-blue-700 text-white h-14">
  <h1>Navigation</h1>
  <ul class="flex justify-between w-56">
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
    <a href="#">
      <li>Link</li>
    </a>
  </ul>
</nav>

There's a demo below the article.

Now that wasn't too much to write and we got a pretty solid navigation bar! If we wanted to change things on smaller or bigger devices, we can make use of prefixes again. Tailwind, much like Bootstrap, comes with predefined breakpoints (media queries) that are named as follows:

sm 640px
md 768px
lg 1024px
xl 1280px

Those can be seen as replacements for media queries in your CSS and when introducing them, the unprefixed version we have used so far will only be applied above the prefixed version. So if we were to use a class with the prefix md:bg-blue and also have a class bg-yellow applied to the same element, the background would only be blue for everything above 768px (md) and yellow below that breakpoint.

Just like predefined breakpoints, Tailwind comes with a set of spacings for paddings and margins that can be applied to either one or multiple sides of an element, basically making it a great alternative to margin-top: x; and similar declarations. All spacing adhere to the following syntax m{t|r|b|l}-{size} which translates to a class like mt-8 for a margin top of "8", where 8 translates to 2rem. Those values are as mentioned predefined but can be adapted when using a real build step. It's definitely worth checking out the Tailwind documentation for exact values and in general a good idea to get a more in depth understanding of everything described in this article.

Next steps and alternatives

A lot of the advantages of Tailwind actually come from using a build step and creating our own configurations. This step allows us to define new colors, spacings, fonts, and much more! It's like keeping all the benefits of the utility-first approach but making it your own and adjusting it to your design and requirements. A lot of people seem to skip this step, which is why we see a lot of sites out there these days that use the default Tailwind styles. Don't get me wrong – that's not a bad thing! But you are missing out when not making use of those customizations. In fact, I think it is so important, I want to dedicate another full article to customizing Tailwind.

In the meantime, there are also other utility-first frameworks that came before Tailwind and there will probably be a bunch more to come. Here are some really interesting ones I recommend checking out.

https://basscss.com/

https://tachyons.io/

https://yogurtcss.netlify.app/

https://tedconf.github.io/shed-css/index.html

https://turretcss.com/

And lastly, here's a working demo to play around with, which contains the basic examples shown in the article.
https://codepen.io/allroundio/pen/VwPWaJa

More on creating custom layouts with Tailwind soon.
In the meantime, feel free to check out all other articles at allround.io