DEV Community: Kevin Pennekamp

A nth-child CSS trick

Kevin Pennekamp — Wed, 25 Jan 2023 15:27:06 +0000

Sometimes you figure out a cool trick that just feels so powerful. It opens you up to a range of new possibilities. That you, quite frankly, rarely use. But still, it is a cool trick. For me, the latest of these tricks is setting a CSS custom property value, corresponding with the :nth-child value. Why? Because now we can use the --nth-child custom property inside calc() functions.

But why not use X?

Sure, in most, if not all, of my projects I use SCSS instead of CSS. But CSS is getting more and more features, making SCSS redundant for me. Looking at you CSS nesting. With each trick or implementation, you can remove another dependency on SCSS, and go back to plain CSS. Using @for-loops makes it easy to achieve the same result. But you will generate roughly the same CSS selector several times.

You might also think using :nth-child(n) would allow you to achieve the same, without all the custom properties. Unfortunately, the n is not useable in the calc() function. So, we use custom properties.

How to set it up

On the highest level of your CSS, you define a list like the one below. This results in all elements having access to a --nth-child custom property. At least as long as you don’t exceed the length of your list.

:nth-child(1) { --nth-child: 1 }
:nth-child(2) { --nth-child: 2 }
:nth-child(3) { --nth-child: 3 }
:nth-child(4) { --nth-child: 4 }
:nth-child(5) { --nth-child: 5 }

What can we do with this trick?

Glad you asked! In the last few years, I came across two use cases. Two, whole, use cases. In the latest use case, I wanted to automatically generate a color palette. Not to match a branding of a company. But to automatically populate different series of data in a chart. With this trick, we can do that with a single line.

background-color: hsl(calc(100 * var(--nth-child)) 100% 40%);

In an earlier use case, I replicated the UI implementation of toasts from Vercel. On the link, you see a list of toast messages stacked with a little bit of perspective. I originally used an SCSS implementation, looking like the snippet below. Note it uses :nth-last-of-type, given the reversed order and bottom orientation. But the general idea remains the same.

@for $i from 1 through 20 {
    &:nth-of-type(#{$i}) {
      opacity: 1 - 0.15 * ($i - 1);
      transform:
          translate3d(50%, 0 - (5 * ($i - 1)) + px, -1 * $i + px) 
          scale(1 - (0.05 * ($i - 1)));
    }
}

This would create twenty different CSS selectors, all with a different value for $i. But using this little trick, we can reduce the code, and make it more maintainable in the process.

.class {
    /* We want to start counting at 0 */
    --v: var(--nth-last-child) - 1;
    opacity: 1 - calc(var(--v) * 0.15);
    transform:
        translate3d(
            50%, 
            calc(-5px * var(--v)), 
            calc(-1px * var(--v)) 
        scale(calc(1 - var(--v) * 0.05);
}

That was it. That was my latest CSS trick.

Creating a stacked bar chart using only CSS

Kevin Pennekamp — Mon, 23 Jan 2023 08:37:12 +0000

In various projects, I always seem to struggle with responsive charts. These libraries generate charts in SVGs, often with fixed dimensions or ratios. This means that different screen sizes either get additional whitespace, or parts of the chart get hidden. Horrible. So I gave myself a challenge to create a responsive CSS-only bar chart, the one visualized below.

The base of the chart

Alright, let’s first make the graph itself. The graph is nothing more than multiple bars aligned horizontally. Or, you know, in a row. As we want all the bars to stick to the bottom, we need to set align-items: flex-end. Floating bars from the top look cool, but in the end, add little value to most charts. The gap is needed to tell each of the bars apart.

.chart {
    display: flex;
    flex-direction: row;
    align-items: flex-end;
    gap: 2px;
}

<div class="chart"></div>

Now we can start defining our bars. Each of the bars is a vertical stack of sections. So, a flexbox with the direction column would suffice. With the flex-grow: 1 we ensure the bars fill up all the available horizontal space equally. As you can see in the example, we do expect that a bar that is being hovered gets more space. This allows us to display values with the bar the user is (kinda) interacting with.

.bar {
    display: flex;
    flex-direction: column;
    flex-grow: 1;
}

.bar:hover {
    flex-grow: 6;
}

The size of the bars

Now we only need to determine the height of each of the bars. Ideally, I would have liked to use a data-* attribute. Reading values in CSS from these attributes can be done using the attr() function, as it only works with string values, and. But unfortunately, that will not work.

The attr() function can only work with string values. This means it only has value for the content attribute in CSS.

The only way I could make it work is by adjusting custom properties via the style attribute on the HTML element, like shown below. It’s not a solution I prefer, but for our use case, it does work. And combined with modern JavaScript frameworks it is often hidden for developers in custom UI components.

<div class="chart">
    <div class="bar" style="--bar-ratio: 68%;"></div>
</div>

As you can see in both the HTML snippet above and the CSS snippet below, we are working with percentages. To have the chart scale nicely, we need to give the bar with the highest value a height of 100%, and all others scale according to their values.

.bar {
    height: var(--bar-ratio, 0%);
}

Stacking the bars

As we are looking at a stacked bar chart, we need to add sections to each of the bars. We already know that a bar is set up as a vertical flexbox. To ensure each section fills up the space of the bar corresponding to their value. If we have three sections with values 10, 20, and 30, we can achieve the result to set flex-grow to this value. In summary, flex-grow: var(--value). Like with the height of the bar, we need to inject the value through the style=“--value: 30;” tag.

If the value is small compared to the other sections, other CSS attributes, such as padding, might impact the correct distribution.

.section {
    display: flex;
    flex-grow: var(--value);
}

.section:hover {
    flex-grow: calc(10 * var(--value));
}

From a user experience perspective, we want to highlight the section on interactivity, i.e. hover. By simply expanding the flex-grow, just like with the bar, we get the effect that we want. Both the bar within the entire chart, as the section in the bar is expanding in size on hover.

Improve the experience

Stacked bar charts visualize different series of data. Each nth section of a bar belongs to the same series of data. This means we need to have a way to indicate that they belong to each other. In most libraries, you can define a set of colors. But I wanted a more CSS-only solution. I already deviated from this by setting values through the style attribute. So I want to avoid more deviation.

A nifty little trick that I learned is setting a --nth-child custom property in the root of your styling, as shown below. This makes it possible to use these values with the calc() function.

You might think using :nth-child(n) would allow you to achieve the same, without all the custom properties. Unfortunately, the n is not useable in the calc() function.

:nth-child(1) { --nth-child: 1 }
:nth-child(2) { --nth-child: 2 }
:nth-child(3) { --nth-child: 3 }
:nth-child(4) { --nth-child: 4 }
:nth-child(5) { --nth-child: 5 }

:::
If you have different types of children within a parent, you can use :nth-of-type. This does target HTML tags. If you only use <div /> it will make no difference.
:::

Now we have a variable that we can use to indicate the index of an element. We can use math to visualize sections of the same series. Examples are background-color or opacity. Let’s go for background-color. The easiest way would be to use the hsl() function and change the degrees of the colors, as shown below. As there are 256 degrees, taking a base of 100 gives us at least six different colors, before colors (almost) start looking the same.

.section {
    background-color: hsl(calc(100 * var(--nth-child)) 100% 40%);
}

Wrapping up

By combining different forms of flexbox, :hover and some small tricks, we can create a nice responsive bar chart. The only downside is you need to bind the values via the style attribute in the HTML templates. This should not be an issue in most modern frameworks. But, it is still something to be aware of. Curious about the live example? Then visit this codepen.io link.

Authentication token management

Kevin Pennekamp — Thu, 18 Nov 2021 13:24:43 +0000

In several large projects (React-based SPA applications) managing authentication tokens is a challenge. These solutions implement an OAuth flow using access and refresh tokens. Many of these types of applications live in an enterprise or business setting. This means users are often logged in to the application a lot longer than the access token is valid. The access token needs to be refreshed in the background.

But that is not the only issue. Many pages need more than one GET request when it is loaded. This adds an extra dimension to the issue. A dashboard where each card requires different data is a good example. Many solutions cannot handle such a situation and result in many refresh attempts that happen at the same time.

The flow of the solution

Solving this issue in complex applications can be done in several ways. A brute-force way is to refresh the access token on each outgoing request, or page navigation. But this means that every user action requires at least one more network request. This would decrease the performance of the application, and thus the user experience.

A second solution would refresh when you hit a 401 HTTP error (unauthorized) from the server. This would create a hit on user experience only once within the expiration timeframe. But this hit can be significant. First, we have to do a request to the server. We get back a 401. Now we have to refresh the tokens and execute the requests again. Three requests instead of one.

My proposed solution is to proactively refresh the token. We know when it expires. Before each request, we can check if the token is expired. When this happens, we can send refresh the token before we execute the original request. The user experience is less decreased compared to the previous solution. But this solution still has an issue. It cannot handle many requests at the same time that need refreshing. By introducing a queue and an extra check, this can be solved. All requests that need to be sent out while the application is refreshing are put in the queue. Once refreshing is complete, the queue is emptied.

The code

The core of this solution is replacing the standard fetch requests, with a fetchOrRefresh request. An example implementation can be seen in the code block below.

const cache = { refreshing: null, expiresOn: '2021-11-01T00:00:00.000Z' };

export default async function fetchOrRefresh(...args) {
    try {
        if (new Date() > new Date(cache.expiresOn)) {
            if (!cache.refreshing) cache.refreshing = refresh();
            await cache.refreshing;
            cache.refreshing = null;
        }
        return await fetch(...args);
    } catch (e) {
        console.log(e);
    }
}

The example also uses a simple object to store information, but a central application state that can be used is a better solution. Lastly, the refresh function itself is not filled in. When you solve two 'blanks' you are able to use this code as middleware in libraries like axios and redux.

Wrapping up

Large applications used in a business setting often see long user sessions. This requires us to ensure authentication tokens are refreshed in the background. But, complex applications have many requests happening at the same time. Many solutions cannot handle this and result in many refresh attempts. The flow and code example introduced in this post can help you overcome these issues without impacting the user experience.

Code stability and interdependencies

Kevin Pennekamp — Wed, 15 Sep 2021 17:39:37 +0000

As engineers, we have the tendency to over-engineer our solutions, make our code as reusable as possible. We make our code DRY (don't repeat yourself). Although these are good rules to go by in most cases, they can also lead to problematic maintenance issues. In our DRY-quest, we can create unstable, yet reusable code that is used in more than one place. Sometimes it is ok to write our code WET (write everything twice). Why? Because it creates more stable code around interdependencies.

The stability rule

The stability rule is very simple. In this rule, stability means the likeliness the code will change. Every function, module, or UI component we write, is as stable as the lowest stability of its dependencies. Think about it. If a dependency changes, our code has to (potentially) change as well.

Every function, module, or UI component we write, is as stable as the lowest stability of its dependencies

But how do you determine the stability of dependencies? This is, unfortunately, no exact science. It depends heavily on the type of dependency as well. We can set third-party packages to fixed version numbers, making them very stable. We can assume browsers API will, most likely, not change. But the code we write ourselves can change. You can measure how many times a function/module changes, or you can make a guess how likely it will change. In both cases, you can give a function or module a score of its stability. With this score, you can create a dependency graph of your codebase, like the one below.

In the above graph, we see that 'Function B' is dependent on 'Function A' and 'Package A'. Function B uses Function A and Package A. All elements also got a score attached. The higher the score, the more stable the element. The ones with a keen eye will see the above dependency graph is actually wrong. It does not comply with the stability rule. The score of 'Component A' cannot be 7, as they depend on a function with lower stability. We have either have to update the graph or change our code.

Splitting code

Based on mismatching stability scores, we can find possible improvements. It allows us to reorder code to improve its stability. But, it also allows for conscious decisions to not change anything at all. In our example, it is highly likely that 'Function B' is only unstable because it has some code only used for 'Component B'. At this point we have three options:

Split 'Function B' into two functions. One function contains stable code used by both components. Another function contains code used by 'Component B'.
Migrate the unstable part of 'Function B' to 'Component B'. This makes 'Function B' smaller, but more stable.
Don't change anything.

We find ourselves with these examples more often than we would like to admit. How many times have you thought: "if I add this option to the function, I can use it here as well". This is the moment where we need to look at the dependencies and their stabilities. Only then will we achieve stable code.

Systems, architecture, and patterns

Most of our time spent during development is around unstable code. We focus on implementing UI and features that are each unique and add a different value to a user or business. This makes the code by default less reusable. But, these features are built upon systems, architectural decisions, and patterns. These dependencies allow us to stabilize a certain core of the application. Some examples:

A design system or UI library provides stable low-level UI components that can be used in many different UI components. Think of input fields, buttons, tables, or even cards.
In React you can create generic hooks abstracting low-level logic (e.g. fetching data, including loading state).
Standardized object validation logic through libraries as Yup or schematiq.
Standardize fetch requests and state management around basic CRUD operations.
Adopt an architecture or design patterns (e.g. client-side reference architecture) that help you determine which parts should be stable. Patterns and consistent architecture help to create imaginary boundaries between functions and modules as well.

And many more ways can be found to stabilize parts of your codebase. Everybody following a recent tutorial knows packages like lodash. These packages or ideas, regardless if you build them yourself, or download them, help you create maintainable code.

Wrapping up

Determining the correct interdependencies on code stability is no exact science. You can measure how often code changes. But, when determining interdependencies, you have to look into the future. You have to determine how likely code is to change in the future. This is not something you do every day. You are not going to create a dependency graph for each change. But having a sense of stability on various levels helps a lot. You will see the quality of your code increase and become more maintainable.

Demystifying state management

Kevin Pennekamp — Thu, 26 Aug 2021 05:52:21 +0000

State management is one of the most complicated, and opinionated topics in modern and JavaScript-focused front-end development. But at its core, it is not that complicated. We just make it complicated. In this article I will try to demystify state and state management for you, and challenge your mental models around them.

What are state and state management?

Is state some weird data storage? Is it the data from a database? No. State is nothing more than a JavaScript value that lives within in scope. It can be a boolean, a string, but is in most cases a (complex) object. But it remains a value. In most cases, it is even an object living on the same level as the window object. It has become a global value in the JavaScript environment, the browser window. From our code (e.g. UI components), we can use this value to determine what to show or what interactions to allow. In complex applications there are a few different types of state we can have. But remember, they are nothing more than values.

Local: state that is used by a single UI component.
Shared: state that is used by many UI components. It is often managed in a parent or wrapper component.
Global: a special kind of shared state, as it lives on the highest level, accessible to all UI components (or even helper functions).
Meta: also known as 'state about state'. It tells you something about
Route: state stored in the current URL of the application (e.g. object IDs or pagination information).
Remote: a copy of the data coming from a server. The responses of fetch requests are stored as 1-on-1 copies in this state. It should not deviate from the server (except when applying optimistic UI).

So what about state management? For many, state management feels like a black box. What is happening within Redux? Why does it feel so complicated. I look at it this way: state management is nothing more than patterns we use to make using and changing state, manageable. It is not black box magic, it is just patterns. Why not group all the mutations you can make on your state in one place? And how about giving these mutations simple, but understandable names? In complex applications, adopting these types of patterns makes our code more maintainable. Or so they say (it is true though). In the sections below, we go deeper into different kind of state management patterns.

Event-driven pattern

The best-known pattern is the flux pattern. It gained popularity with the 'Redux' package. It is a great example of an event-driven pattern. Let's take a closer look at its flow. The user, via the view, dispatches an action, via an action creator. It might seem daunting or overly complex. But it is nothing more as I said before. It is a way to group all possible state mutations together, and allow us to use simple 'actions' with memorable names from our UI components.

Such a pattern allows us to keep the code in our UI components small and clean. When hitting an issue where our state takes the wrong shape, we know where to look. That is why it is called state management.

A core concept that came with this pattern are reducers. Reducers are these big complex switch statements that hold all our state mutation logic. They can really feel like a black box sometimes. But don't get fooled. The concept is really simple. When removing the complexity of the switch statement your are left with something like the snippet below. A reducer is a simple function that gets a state and returns a state. Nothing more, nothing less. It uses additional input to mutate the state in between, or don't do anything at all.

function reducer(state, { action, payload }) {
  ...
  return newState;
}

Redux relies heavily on reducers. When setting things up, you add all your reducers to your Redux store. Redux really takes event-driven from server-side patterns at heart. All reducers are allowed to act upon the dispatched actions. However, I cannot say I have seen this happen in production(-like) environment.

Event-driven state management is related to state machines. State machines allow us to clearly define the shape of the state, and when which mutation is allowed. Below is an example of a state machine for an animated toast message. This toast message should disappear after X seconds. The Redux style guide shows you how to model reducers into state machines. If this feels complicated, you can get a long way by adding if-statements in your switch statements. "You can do action X if we are in state Y".

Atomic pattern

Many state management libraries force you to create one big state that lives on the highest level of the application. This came in a time where we put our 'remote' state in this store. But solutions like React Query, SWR and Apollo Client handle this for us now. Less and less data needs to get managed on a global level. The need to inject your store setup in your highest-level component wrapper also became redundant.

With an atomic pattern, we have many different global states of single values. Its approach really embraces the nature of JavaScript and the idea that state are just values. Each atom is a single value. In most cases, atoms also live on the global level in the JavaScript environment. However, you don't have to define all atoms in one place. If you modularize your application, you can have the code of different atoms live in different modules. You group atoms closely to where you use them. You colocate them.

This gives the pattern a decoupled nature. You don't have to configure all atoms in a generic store. Also, they do not have to be directly injected into your UI component wrapper. Most frameworks allow you (e.g. via hooks) to interact with atoms in components directly. Lastly, atoms can be combined (in most implementations). This means you can use atoms in other atoms. When an underlying atom changes, the parent atom changes as well. You don't have to worry about re-render or listening, it is all managed for you.

It does have some downsides. When the number of atoms grows, managing them can become a hassle. You have to name them all, and you have to be aware that they exist. Also, managing a complex structure of dependencies between atoms can become quite a task for developers.

Reactivity and proxies

Many modern front-end frameworks are reactive. When a state changes, the framework knows that it should re-render. Or in other words, the state lets the framework knows it changed. This mental model is very like a proxy. A proxy is a wrapper object that is being called, instead of accessing the targeted object . This allows us to add custom behavior to various calls.

Proxies are ideal to create reactive and robust state management. The basic power lays in the fact that we can add listeners to state changes. Besides, the values of a proxy can directly be changed. You do not have to invoke the change via a function. If you want to create a more complex proxy, you could implement validators that validate changes before applying a state change. You could even add several layers of 'middleware' before each state change. You can go nuts.

const store = proxy(() => ({ count: 0 }));
const listener = (c) => console.log('Count updated:', c);
store.on('count', listener);
store.count++;
// Count updated: 1

The code snippet above shows an example proxy. As you can see, we add a listener function for when the value of count changes. Now when we change the value of count, the listener function is triggered. Do note that this particular implementation is not immutable. You can change the value . Many people prefer to have an immutable state, as it is less prone to development errors.

Wrapping up

Now you should have a better understanding of some fundamentals of state management. Knowing the different types of state and how to manage state is the start. With proper state management, you can get a long way in complex web applications. But it is the start. There are many (more) ways to manage data that are important in client-side applications. When you master state, go dive into persistent storage or caching.

Horizontal centering in CSS

Kevin Pennekamp — Sun, 20 Jun 2021 11:17:42 +0000

In a previous article I wrote about modern CSS layout solutions. As horizontal centering is a common layout pattern, the grid-based solution was a prime candidate to convert into a generic class when creating Feo CSS. But I encountered an issue. When combining this solution with other CSS layout patterns (e.g. the flow pattern) my layout would break. Both patterns are targeting the display property, but with different values. To allow both patterns to work together, I had to find a different solution.

The center layout pattern

The center layout pattern allows you to horizontally center elements on the screen. But more importantly, it allows child elements to have a different width as the parent. These can be images that span the entire width of the screen in articles, regardless of the screen size. Or when we want selected elements to break away from the paddings on the side. On small screens, we want small padding around the text, and images span the entire width.

CSS grid-based solution

This solution creates a three-column grid. The outer columns act as the padding and overflow of the layout. By giving them a minimum width via minmax(1rem, 1fr), you ensure small padding exists on small screens. The center column takes the space required for the content but is capped at the maximum width. You can achieve this with minmax(auto, 60ch). This gives the combined implementation as displayed below.

:::
The used examples make use of CSS custom properties. This allows for adjustable layouts based on utility classes. Examples can be found in Feo CSS.
:::

.center {
  --gap: 1rem;
  --mw: 50rem;

    display: grid;
    grid-template-columns:
        minmax(var(--gap), 1fr)
        minmax(auto, var(--mw))
        minmax(var(--gap), 1fr);
}

/* Center all children */
.center > * {
    grid-column: 2;
}

By overwriting the default grid-column: 2 to grid-column: 1 / -1, you can achieve the effect described in the previous section. This effectively makes the element the same width as the entire grid, not only the center column.

.center > .exception {
    grid-column: 1 / -1;
    width: 100%;
}

But this has a downside: does not allow to set a different display value on the parent element. This makes .center less useful for non-article-based elements.

Back to the old school solution

In finding a solution for my problem, I looked at the solution that was used years before CSS grid became a thing. On Stack Overflow, you will still find enough answers pointing to this solution. Of course, I am talking about the margin: 0 auto solution. Let's modernize it a bit though.

.center {
  --gap: 1rem;
  --mw: 50rem;

  width: 100%;
  max-width: var(--mw);
  margin-left: auto;
  margin-right: auto;
  padding-left: var(--gap);
  padding-right: var(--gap);
}

This is always a solid solution for horizontally centering solutions. But it has one issue though, and the reason why I did not use it in the first place. It does not easily allow child elements to 'overflow' and has an increased width. This issue can be avoided by using the method below. However, I found that this gave me issues with the responsiveness of the exception elements. So my search for a better solution continued.

.exception {
    width: 100vw;
    position: relative;
    left: 50%;
    transform: translateX(-50%);
}

Out with the old, in with new

By slightly adjusting the old school solution, we can create a class that allows for the same behavior as the shown grid-based solution. Instead of setting the properties on the parent, you should set the same properties on the children by using the child combinator (parent > child). Similar to the grid-based solution, we can create a .exception class. When children are given this class, they are allowed to have a different width. They can flow outside of the parent's boundaries.

.center > * { ... }

.center > .exception-1 {
  max-width: none;
}

/* a solution with a different max-width */
.center > .exception-2 {
  max-width: min(100%, 50rem);
  padding-left: 0;
  padding-right: 0;
}

Setting the max-width to none allows a child element to have no restrictions on its width. It can become 100% while all the other elements are capped at a maximum of 50rem. Similar to the grid-based solution, you can now create more dynamic layouts. The use of CSS custom properties even allows you to define utility classes that gave you more control over the layout.

.center-g-sm > * {
  --gap: 0.5rem;
}

Wrapping up

The grid-based solution works well for articles. But when converting the class to a generic layout pattern, I encountered some issues. The main issue was that the display property on the parent was taken. By altering the solution used many years before CSS grids became a thing, I was able to come with a new solution. This creates the same layout with the same responsiveness advantages but gives me more flexibility. I am sure I will encounter another case where my new solution just does not work well. But for now, I settled for it.

Creating an auto-layout algorithm for graphs

Kevin Pennekamp — Thu, 10 Jun 2021 19:58:00 +0000

In the last few months I worked on a finite state machine editor build on React Flow. At a certain point I wanted to import a configuration, that magically visualizes the state machine. I was in the need of a graph layout algorithm. A few years back, I have implemented a similar feature for a workflow editor. The biggest problem to solve? Ensuring the resulting visualization is understandable and readable. This requires a solid algorithm.

If all nodes in the graph are scattered across the screen, it will become hard to follow the lines between them. The approach I took is based on the paper "A technique for drawing directed graphs (1993)". It is a technique based on finding a (local) minimum in the number of crossing edges, as visualized below. My implementation consists out of three steps: (1) rank all nodes, (2) optimize the order of the nodes, and (3) determine the position of each node.

Rank all nodes

The first step of the algorithm is to rank all nodes. All graphs have an initial node. It is the starting point of a process/workflow or the initial state of a state machine. This particular node is placed in rank 0. With this starting point, we follow three steps to determine an initial rank for all the nodes.

Determine the initial rank of each node. The rank of a node equals the length of the shortest route between this node and the initial node. The rank can be determined using a breadth-first search algorithm.
Determine all possible paths from the starting node, using a depth-first search algorithm, like displayed below.
Order all nodes within a rank, based on their occurrence in the longest path. Nodes in longer paths are placed higher within a rank.

function getPaths(nodeId, edges, path = [], paths = []) {
  const children = edges.filter((e) => e.source === nodeId);

  const _path = [...path, nodeId];

  // To avoid cycles in paths
  if (path.includes(nodeId)) {
    paths.push(path);
  } else if (!children || children.length === 0) {
    paths.push(_path);
  } else {
    children.map((c) => getAllPaths(c.target, edges, _path, paths));
  }

  return paths.sort();
}

The example below visualizes a result when following these steps. You can see that all nodes are ranked as described. In this example, node 4 is placed at the top of rank 2, as it appears in the longest path, while node 5 does not.

Optimize the order of the nodes

The above visualization shows that ranking nodes following these steps can produce readable results. But, improvements can be achieved. As this is a so-called 'NP-hard' problem, there is no perfect solution possible. But, by following a certain sequence of steps, several times until we hit a boundary condition, we can approach a (local) optimum. Or you know, the minimum number of crossing edges. This is called a heuristic.

A heuristic is a practical problem-solving approach that is not guaranteed to be optimal, perfect, or rational. It is enough for an (intermediate) goal.

A vital part of this heuristic is the ability to give a configuration a score. This score is used to compare various mutations of the graph and find a (local) best based on this score. As mentioned before, the idea of this algorithm revolves around minimizing the amount of crossing edges. Thus, our score needs to be related to that. An easy scoring mechanism can be:

Count the number of edges that have the source and target in the same rank and are not next to each other. You can also count the number of nodes between them. This would give a higher score when the source and target are further apart.
Look at all combinations of ranks and count all edges between these two ranks (regardless of their directions), where the condition shown below is met.

// Assumes both edges have the source in a lower rank
// edge = [sourceIndexInRank, targetIndexInRank]

function edgesCross(edge1, edge2) {
  if (edge1[0] < edge2[0] && edge1[1] > edge2[1]) {
    return true;
  } else if (edge1[0] < edge2[0] && edge1[1] > edge2[1]) {
    return true;
  }
  return false;
}

With the scoring mechanism determined, it's time to look at the actual heuristic. The heuristic I choose is iteratively moving through all ranks and swaps two adjacent nodes. If they improve (or at least not worsen) the score, the mutation stays, for now. As this mechanism is not perfect, as not all possible mutations are explored, we can apply this heuristic for a maximum of X times, to balance between performance and optimal results. The detailed steps of the heuristic are outlined below.

Let i = 1 and move to rank[i].
Let j = 0. Swap rank[i][j] with rank[i][j + 1].
Determine the score of the new graph, if the score becomes worse, reverse the mutation, else keep the mutation.
Set j = j + 1 if possible, else set i = i + 1 if possible, and repeat step 2. If neither is possible, proceed to step 5.
If the resulting graph has a better score, repeat step 1 for the new graph, for a maximum of X times. Else you found a (local) optimum.

The example graph used before has two crossing edges. By applying the above heuristic, we can optimize this by applying two mutations, as visualized above. When we swap nodes 2 and 3, we are getting the same score of 2. This means to apply the mutation and continue. Nodes 2 and 9 cannot be swapped, as it worsens the score of the graph. When swapping 4 and 5 after swapping 2 and 3, we find a perfect score and thus our resulting graph.

Determine the position of each node

After we have optimized all our ranks of nodes, it is time to determine the position of each node. Various routes can be taken, but the easiest is to place nodes in a grid. In the end, our ranks are a grid. This is illustrated below, using the running example from the previous sections. By using a grid, you create several options for yourself to lay out your graph. You can take a traditional route, like the visualization shown in the previous section.

You could also go for a more balanced graph, where all nodes are laid out around a centerline. In your initial rank, you always have one node. Depending on the orientation of your graph, this initial node is placed on a horizontal or vertical centerline. As you can see in the example, nodes 1, 2, and 8 all line on this centerline, instead of having five nodes on a single line.

|   |   | 3 |   |   |   |   |   |   |
|   |   |   |   | 5 |   | 6 |   |   |
| 1 |   | 2 |   |   |   |   |   | 8 |
|   |   |   |   | 4 |   | 7 |   |   |
|   |   | 9 |   |   |   |   |   |   |

Wrapping up

Solving the automatic (or magical) layout of a directed graph (or state machine) is one of the most fun challenges I ever had. By doing research I found an algorithm I understood and could put in place. The described algorithm proves to be effective for small to medium-sized graphs. Most of these graphs are not spiderwebs and have limited edges (e.g. 2-3 outgoing edges per node). Don't believe me? I use the algorithm in an online state machine editor I have created. But, it is a heuristic and by definition not perfect. Some improvements I can think of already are:

Make it possible to change the weight of certain types of crossing edges (e.g. edges crossing with a rank have a higher weight). This allows you to control the algorithm to your own needs.
Allow for nodes to move between ranks during the optimization step. This is a helpful improvement when you have a graph with a fixed start and end node, but a big variation in the length of paths.
Optimize how mutations and which mutations are applied. Check only adjacent ranks to improve the performance for example. This can worsen the result though.

I've created a JavaScript package called DIGL that implements the described algorithm. It is framework agnostic and can be used in the front-end or back-end.

Binding CSS and JavaScript with HTML data-attributes

Kevin Pennekamp — Sun, 25 Apr 2021 09:02:53 +0000

My CSS architecture is based on CUBE CSS. One of the layers of CUBE CSS describes exceptions. Although I see exceptions as an integral part of the block layer, they are important nonetheless. Exceptions are often captured by targeting semantic HTML attributes or data-* attributes in your CSS selectors. But what do these attributes enable you to do in CSS?

Introducing HTML `data-*` attributes

HTML 5 was designed with extensibility in mind. On the data level, this is achieved with data-* attributes. They allow you to define your attributes on HTML elements. By using the data- prefix you cannot define non-existing attributes, or override attributes with non-valid values. If you did, you would invalidate your HTML. But with the data-* attributes you are free to add whatever your heart desires. Let's take a closer look at how this looks in HTML.

<button data-type="primary">Click me!</button>

In this example, we added the data-type attribute to a button, with the value primary. All UIs have multiple types of buttons. Most CSS implementations choose to create a base .btn class. On top of this class, we define the modifier from the BEM notation. In this case, .btn--primary. Should be enough, right?

Now assume the case where you use an existing UI library for your buttons. Most of these come with a predefined set of button types. But now you want to create another type? Though luck. The library does not allow for defining button types and their styles yourself. You are not able to extend the stylesheet with a style definition for your newtype button, extending the .ui-btn class of the library.

.ui-btn[data-type='newtype'] {
    background-color: red;
}

This definition has a higher specificity compared to the .ui-btn. It will override any styles defined in the default .ui-btn class.

Linking JavaScript and CSS

Although defined in HTML, data-* attributes play a very important part in linking JavaScript with CSS. Many front-end developers tend to use JavaScript to define what CSS classes should be applied to an element. Modern JavaScript frameworks like React make this very easy. Although nothing is wrong with this approach, your code can become unmaintainable quickly. You often go to string manipulations to determine the modifier class it needs to apply.

function MyComponent({ type = 'primary' }) {
    const classes = `ui-btn ui-btn--${type}`;

    return <button className={classes}>Click Me!</button>;
}

If you forget to define the default value of a property, you apply ui-btn ui-btn--undefined to your element. What happens when there is more than one type of modifier that can be applied to your element? Your code became a lot less maintainable. By utilizing data-* attributes you can avoid this. It allows you to minimize the amount of JavaScript required to determine which styles need to be applied.

On the other hand, it powers up your CSS. The data-* attributes allow you the apply pattern matching as well. 'Contains' (*=), 'starts with' (^=), or 'part of list' (~=) are just some pattern matching examples. You can even apply matching using a case insensitive query using [data-type='primary' i] in your CSS. But when would you match patterns? Is this not a too complex feature for CSS?

Using `data-*` for real-life scenarios

Let's take a look at an example to show why it can be of value. Everybody loves creating tables in Excel. You add some bold font to the header cells, as they indicate what information is present in the columns. And the same goes for the first column, as those cells indicate what is in the rows. Maybe you go exotic and apply even more styling next to some bold fonts. Something similar can be created using data-*. Look at the partial code-snippet below.

<div class="data-grid">
    <div class="cell" data-type="first-row first-column" />
    <div class="cell" data-type="first-column" />
</div>

In the code below, we can target both cells with the displayed CSS selector. As both cells have a different data-type we cannot apply one-on-one pattern matching. But with the ~= operator, we can search if the value is present in a 'space separated list'. So with the CSS selector below, we can target both cells with one definition.

// targets all cells in the first column
.cell[data-type~='first-column'] {
    background-color: red;
}

State machines

But one of the biggest advantages of data-* has not yet been discussed: state machines! State machines are upcoming in front-end development but are an old concept. As outlined in this article on CSS-tricks, state machines allow you to simplify your code by mitigating side-effects (e.g. in fetch requests). It is a powerful method to define complex logic. If an element requires different styling based on the state, data-* are here to help you out! It is as simple as the snippet below.

.my-element[data-state='init'] {
    background-color: red;
}

A state machine is a machine that can be in one state at any given time. The machine can change from one state to another, based on transitions. A statechart allows for nesting, delays, automatic transitions, and parallel regions in state machines.

State machines have a lot of value in complex state management. In those cases, styling is often not impacted. Parts of the DOM tree are disregarded based on the current state. Although this could also be achieved with CSS (display: none), it is not the main strength of combining CSS and state machines. I have listed more practical use cases below.

Disabling interactive elements (e.g. buttons) based on the loading state of fetch requests, and provide visual guidance.
Different visualization of checkboxes (checked, unchecked, semi-checked).
Different combinations of (un-)selected, hovering, and active.
CSS animations based on statecharts with timers (e.g. fly-out animation).

By combining semantic HTML, HTML-attributes and data-* attributes, styling based on states can be made possible. It allows you to reduce the amount of JavaScript and use CSS what it is intended for in the first place: layout and styling.

Wrapping up

Good use of semantic HTML attributes make it possible to link CSS to JavaScript. As we have seen, the data-* attributes allow the creation of generic UI components that are styling less. Instead of imposing an opinionated style, they allow developers to override every aspect. When combined with semantic HTML-attributes, styling for state machines can be implemented, as in line with CUBE CSS.

CSS methodology and architecture

Kevin Pennekamp — Fri, 16 Apr 2021 08:02:54 +0000

For years I have used ITCSS as my goto CSS architecture for large projects. It helped me to keep my CSS maintainable with a small team. But in the last two years, I've found myself applying utilities more, and writing CSS components/blocks less. More and more parts of ITCSS were left untouched and unused. My CSS architecture had become too complex for my daily use. And it was not just me. You see the movement in the community, but also within my own team.

I am a not utility-first guy. But 80% of my CSS code is utilities these days. The remaining parts consist of CSS targeting layouts (e.g. grids) and blocks that could be solved with utilities (e.g. using operators like + or ~). At this point, I came across the CUBE CSS of Andy Bell. It is the methodology describing how I was, and still am, implementing CSS. So as every self-respecting front-end developer with an online presence, I took it, changed it, created a framework, and wrote about it!

From methodology to framework

CUBE CSS is a methodology with simplicity at its core. It values CSS for what it is. The methodology works well with custom properties to implement a framework. The combination creates a flexible, scalable and extensible CSS architecture. The custom properties act as design tokens and can be used across all layers of the architecture. My framework consists of three layers.

Layout: classes that look at the macro-level of an application, like the once I described here. They provide flexible and responsive layout solutions that are common across an application. For inspiration on common layout patterns, check every-layout.dev.
Utilities: classes that do one job and do one job well. This is often a class that alters a single property. But utilities like the .click-area class cover more than a single property but still do only one thing.
Blocks: correspond to UI components. That what cannot be solved with layout and/or utility classes alone can be solved in blocks. You can choose to cover all styles of a component in a block, or you can only put those styles not covered by other classes in a block.

CUBE CSS does include a fourth layer, exceptions. Although I love the data-attributes on HTML tags, I see them as a part of the blocks.

If you look closely at the code of my framework (Feo), it has the architecture outlined below. As you can see, it only focuses on layout and utility classes. Blocks and exceptions are very project-specific, and often tied to UI components. Therefore they are left out of scope in this framework. However, there are many ways how you can add blocks in conjunction with this framework to a project. You can add a directory to the framework, but I would suggest co-locate it near the corresponding UI components. You could do this via CSS modules, styled-components, scoped styles in Svelte, etc.

styles/
├── layout/        // classes for layout patterns
├── utilities/     // utility classes
├── _global.scss   // global styles targeting HTML tags
├── _reset.scss    // CSS reset
├── _tokens.scss   // design tokens
└── index.scss

Implementing and using this correctly requires some basic knowledge about specificity and the cascade. Many of the layout patterns will apply CSS properties with a higher specificity compared to utilities. In some cases, the specificity might be the same, but you should not override layout properties with utilities.

detailed look at the framework

At its core is the _token.scss file. In this file, you define all your design tokens as SCSS variables. But why not define them as custom properties? As the framework is extensible, you should be able to define your own names for the variables, with your preferred names. Do you want to use -xs or -4 as a name for spacing? This makes it impossible to correctly define all utility classes. But by using SCSS variables as the definitions, we can generate custom properties that can be used for all your additional (block) classes.

$colors: (
    'black': #000,
    'white': #fff
);

:root {
    @each $name, $color in $colors {
        --#{$name}: #{$color};
    }
}

With the design tokens, we can generate all utility classes. Instead of setting the value of all the utility classes, we refer to the corresponding custom property, as shown below. Assume you change the value of --black for a specific page to #fff. All utility classes (and blocks) that have a reference to the custom property --black, will now use the value #fff instead of #000 on this specific page. This creates a consistent but flexible experience for both the user and developer. We let the cascade of CSS do its work for custom properties.

@each $name, $color in $colors {
    .bg-#{$name} {
        background-color: var(--#{$name});
    }
}

A similar approach is taken for the layout patterns. Many of the layout patterns still have properties that you want to adjust. Take the example below. This generates a responsive overview of tiles. But you want to be able to set the size of the gap. By generating utility classes we allow developers to set classes like tiles tiles-g-xs on elements. Similarly, other properties can be identified that can be replaced by additional layout utility classes (e.g. replacing the 20rem). Although this flurries the lines between layout and utilities, this is okay. It aids towards the goal of covering 80% of the applied styles with this framework.

.tiles {
    --tiles-gap: var(--spacing-0);

    display: grid;
    grid-row-gap: var(--tiles-gap);
    grid-column-gap: var(--tiles-gap);
    grid-template-columns: repeat(auto-fit, minmax(20rem, 1fr));
    width: 100%;
}

// Generate classes to set the tile gap
@each $name, $space in $spacing {
    .tiles-g-#{$name} {
        --tiles-gap: var(--spacing-#{$name});
    }
}

Wrapping up

The moment I read about CUBE CSS, I was a fan of the methodology. How could I not? It was basically describing how I felt about CSS and how I was using it. At the same time, I became a big fan of customer properties. So why not combine the two into a framework? Which is what I did. The current version of the framework is open on GitHub. It is small but used in two projects. It has several layout and utility classes build in. For now, I intend to continue to improve and enrich the framework when I can. Let me know in the GitHub issues what you think should be added!

Getting my SvelteKit website on Netlify

Kevin Pennekamp — Sat, 10 Apr 2021 18:15:16 +0000

After tackling the development of a SvelteKit version of my website, it is time to get it running in production! Or in this case, hosted on Netlify. It was in this part I found out the hard way that SvelteKit is in beta and not production-ready. Let me take you on my journey to get the website deployed on Netlify, and see if I was successful (spoiler: you are reading this on the SvelteKit version).

Hosting on Netlify

Now that I had my website locally working, I had to get it deployed on Netlify. SvelteKit has an adapter-netlify package. This package creates a Netlify function that acts as the 'server' for the SSR website. So I swapped the default adapter-node to the Netlify version and let GitHub and Netlify do the magic. And... errors.

This is the moment I found out why SvelteKit is still in beta. In general, all the packages are devDependencies. But, the Netlify Functions could not find the packages needed. So I moved the packages from devDependencies into dependencies and hit deploy again. Progress! The Netlify function can now find the package. Some issues remained, but progress nonetheless. Back to the local version to fix them.

But wait a minute? The local version is not working anymore? Apparently, Vite, the local build tool, did not like it when I moved the packages. After trying several things, I gave up. As SvelteKit is still in beta, community resources are scarce. I did found a few Sapper examples, the predecessor of SvelteKit, using the adapter-static. Success! Well... kind of.

I found that a few of my markdown files got transformed into pages correctly, but not all. After searching and debugging, I found the issue. The adapter-static traverses all links starting from the index route and generates pages for all the linked pages it can find. If a markdown file is not present as a link on a page (yet), it does not get generated.

The adapter-static changes the solution from SSR to SSG: the pre-rendered HTML is generated on build time instead of runtime.

Optimizing the website for SEO

In general SSR and SSG are SEO-friendly ways to create modern websites. Both Gatsby and Svelte(Kit) should enable me to create an SEO-friendly website. I used the web.dev measure tool to determine my website score. The homepage of the Gatsby version scored a 100 on all categories. But so does the SvelteKit version.

But the scores are not the only metrics found in this tool. Most metrics were the same for both versions of the website, except time to interactivity. For the Gatsby version, this was around 2.4 seconds, while the SvelteKit version has a time of around 1.0 seconds. Both good scores, but SvelteKit is superior.

Time to interactivity: the actual time it takes to load everything allowing the user to interact with the page

This is driven by the files transferred on loading the page. The Gatsby version had to download around 950 kB across 24 files. The SvelteKit version only needs around 280 kB over 14 files. A big win for SvelteKit!

But we can test more than the homepage. Other pages did not score that well for SvelteKit. One of the bigger issues found by web.dev is redirects. At the moment of building the website, SvelteKit has no trailing slashes in URLs by design. But, Netlify normalizes all URLs to a version with trailing slashes. It adds the below redirect headers to each page.

/post-title /post-title/ 301!

By playing around with the 'Asset optimization' settings on Netlify, I was able to turn off this normalization. After redeploying and re-evaluating, the web.dev scores increased significantly. Now individual post pages score much better compared to their Gatsby counterpart. Especially on the 'time to interactivity' metric.

Turning off all asset optimizations on Netlify increased performance on my website. But, it can have unwanted side-effect due to the lack of URL normalization. Use with caution.

Conclusion

When moving from the stable Gatsby to the unstable SvelteKit public beta, I took a risk. Not only did I have to learn a new framework, I had to build logic to replace community plugins. I was at risk of encountering bugs that few encountered before me. With the knowledge that I could not rely on Google or Stack Overflow, I jumped into the deep. But in the end, it all paid off. I build a new website that is not only faster but more enjoyable for me to work on. The experience that Svelte and SvelteKit bring is promising, and now I cannot shut up about it.

If you are curious about the result, check the code on the open GitHub repository.

Converting my Gatsby website to SvelteKit

Kevin Pennekamp — Sat, 10 Apr 2021 18:09:03 +0000

For the last few weeks or months, I was getting restless about everything: my work, my website, the environment, the World. I had to find something to change my focus to, restore my energy. Around a week or two ago, I found the news of SvelteKit going into public beta. This sparked excitement in myself I had not felt in a long time. So during Easter weekend, while in a Corona lockdown, I started with a new journey. An exciting journey. I was going to learn a new framework and rebuild this website! Or at least, try.

Introducing Svelte and SvelteKit

React is a JavaScript library that makes it easy to write UIs. As it is a library, your code plus the library is shipped to the browser and executed there. Also, you have to write your HTML (or JSX) inside the return of a function, while other lifecycle information is also encapsulated inside that function. Gatsby is a static site generation (SSG) solution build on top of React, and was used in the previous version of this website. An easy next step would be migrating to Next.js, a static-site rendering (SSR) solution build on React. But then I came across the news of the SvelteKit public beta.

SSG vs. SSR: in both cases the server is responsible to pre-render the requested HTML page (in contrast to client-side rendering (CSR)). With SSG this happens at build time: all possible pages get pre-rendered. With SSR this happens at runtime: upon a page visit, the HTML gets pre-rendered using a template.

Svelte is not a library or a framework, it is a compiler. This means that your code is not shipped in combination with packages to a browser, but it gets compiled to something else. This something is shipped to the browser. Because all code gets compiled, the total size decreases, but the performance increases. Besides, it allows you to break away from writing everything inside a JavaScript function, and have its optimized format.

SvelteKit is for Svelte, what Gatsby and NextJS are for React. It is an opinionated framework build on top of Svelte that allows you to create SSR (and SSG) websites and applications. At its core, it uses a flexible filesystem-based routing in the /routes directory. Not only do the templates for the pages in this directory, but the code that runs on the server is co-located here as well. It is the next iteration of the Sapper framework. So a great choice for a blog-driven website.

Working with (S)CSS in SvelteKit

I am a big fan of CSS and have a strong opinion on how it should be applied to websites/projects. My setup allows me to extract general layout patterns and combine them with general utility-first CSS. When I read about the 'scoped' styles of Svelte I got a bit anxious. Would my way of working deviate too much from Svelte(Kit)?

But quickly it hit me. The combination could work perfectly. It could allow me to create global layout and utility CSS, and use the 'scoped' CSS of Svelte to add styles specific to components or pages. The styles defined in the Svelte component could replace the entire block directory of my framework. This means that components would look something like shown below. On the div instead of the header tag, you see various utility classes applied, but also the defined .inner class.

<header>
    <div class="inner | flex-row items-center mb-0">
        <Logo />
    </div>
</header>

<style lang="scss">
  header {
    ...

    .inner { ... }
  }
</style>

This worked beautifully, for the most part. The compiler of Svelte is smart enough to identify unused local styles, and not bundle them. However, in SvelteKit you can render an HTML string using the @html flag. The compiler cannot link the two and will flag local styles as unused. This results in styles not being applied, but also not bundled. You cannot find the styles with the browser Inspection Tool, they do not exist. To solve this issue, the :global() helper has to be used. But except for that, even my opinionated way of working just works.

<style>
    :global(.post h2) { ... }
</style>

I think I am good at CSS, but bad at animations. I know my way around CSS transitions, but that is as far as I go. Luckily Svelte got a lot of sweet stuff built in. The svelte/transition, svelte/animate, svelte/easing (and potentially more) packages really make your life easier. They enabled me to implement page transitions (with the code below), or logo hover animation with ease. These little touches credit the name of my website, Crinkle.

<script>
  import { fly } from 'svelte/transition';
<script>

<main in:fly={{ y: 50, duration: 250 }} />

Setting up the markdown file handling

But I do not write my articles in HTML, Svelte, or React, I write them in markdown. With Gatsby several steps had to be taken to make it all work:

The markdown files inside the /pages directory needed to have a template name indicated as an attribute in the front-matter section.
In the gatsby-node.js file you put the code on how the actual files should be handled. With a GraphQL query, all pages can be retrieved and you can transform the data into the format you require in your template file (e.g. in my case I had to extract the next and previous articles).
The template file, located in a /templates directory allows query (again through GraphQL) an object defined (in my case an article and the adjacent articles) in the previous step can be obtained and transformed into an HTML page through React components.
Configure a shit tone of plugins to handle images, code highlighting, relocation of files, etc. in the gatsby-config.js file.

I don't know about you, but I found it not developer-friendly. Things are scattered everywhere, it is unclear why you have to use GraphQL everywhere, and the plugins obfuscate the actual logic. SvelteKit is much more intuitive. The /routes directory holds the code for rendering the pages, not the markdown files. It combines the /templates and parts of the gatsby-node.js corresponding to a page in one place. This co-location makes much more sense.

The [slug].json.js file contains the logic of transforming a markdown file in a JSON structure that can be sent to a browser. slug corresponds to the filename without the extension. Instead of installing several plugins, I only had to install three npm packages, nothing more, nothing less.

front-matter: to read additional attributes at the top of the markdown file.
markedjs: parse markdown into HTML.
prismjs: add code highlighting.

The resulting JSON string is returned at the end of the function. On the [slug].svelte side, we need to fetch the generated JSON and return it in the props. We can then expose the property as shown below. This allows us to use the article object in the rendering code of this svelte plugin.

<script context="module">
  export async function load({ page, fetch }) {
    const article = await fetch(`/writing/&{page.params.slug}.json`);
    if (res.ok) return { props: { article } };
  }
</script>

<script>
  export let article;
</script>

All the above was sufficient to have my Gatsby website transformed into a SvelteKit website, almost. There were small issues left. For instance, images on the articles were wrapped in a <p></p> tag, which made a styling element I used impossible (until the :has() gets released). But luckily you can alter how markedjs works.

import marked from 'markedjs'; 

marked.Renderer.prototype.paragraph = function (text) {
  if (text.startsWith('<img')) return text;
  return  '<p>' + text + '</p>';
}

With a few more of these alterations (lazy loading of images and anchor tags on headings), I was able to create the same website in SvelteKit. Or even a better website, with less code.

Conclusion

Up until this moment, the development experience (DX) of Svelte and SvelteKit has been tremendous. Don't get me wrong, I loved Gatsby the first time I used it. But after working with Svelte(Kit) I found its DX inferior to SvelteKit. For UI components that do not require (a lot of) state management, Svelte is also superior to React. But when moving to SvelteKit, you loose the community and plugins of Gatsby. This makes Gatsby superior for less tech-savvy people, or when you want to move quicker and do not want to control each detail.

If you are curious about the result, check the code on the open GitHub repository.

Modern CSS grid solutions to common layout problems

Kevin Pennekamp — Mon, 06 Jul 2020 11:33:54 +0000

Layout and composition are some of the most challenging topics within CSS. Especially when you have to take responsiveness into account. We often fall back no media-queries. But adding many media-queries for various breakpoints can make your CSS unmaintainable. But with the addition of grids, we can overcome media-query fatigue. Not only make our CSS more maintainable, but they also improve the user experience. We can let CSS handle the available space. In this article, I will describe three layout implementations that can improve your (personal) website.

Dynamic centered layout

We all know margin: 0 auto to center a layout. Ideal for article pages, right? But what if you want elements like images to exceed the maximum width of the article? We can achieve this by working with negative margins. But this only works on big screens. On small screens, negative margins can break your website. Especially when you apply smaller side padding on mobile compared to tablets. So, we have to add many media-queries to ensure this effect works as intended, on all screen sizes. But now we have our cool effect as visualized below.

What happens when you want to change these ultra-wide elements? You go over several media-queries to determine if your change is applied on various screens. What if we could cut the media-queries and still achieve this effect? Recently I came across this post from Dave Geddes. It shows us how we can achieve this effect using CSS Grids. You create a grid of three columns. The center column is the actual content area, while the two outer columns act as padding, but also create the effect of margin: 0 auto.

article {
  display: grid;
  grid-template-columns:
    minmax(2rem, 1fr)
    minmax(auto, 65ch)
    minmax(2rem, 1fr);
}

/* sets all children in the middle of the screen */
article > * {
  grid-column: 2;
}

/* overrides the above for images to be wider, but centered */
article > img {
  grid-column: 1 / 4;
  justify-self: center;
  width: 100%;
  max-width: 100ch;
}

The paddings on the side should differ on various screen sizes. On smaller screens, you want to limit the wasted space, while on bigger screens more padding can improve the visual quality. But with the above solution you still need media-queries to use different side padding. You could mitigate this by adding fluidity to your website. We can replace the 2rem with something like calc(1rem + 1 * var(--ratio)). By doing so, the side padding changes automatically when the screen size changes, without media-queries. Now we have a dynamic and maintainable layout for our articles.

Responsive multi-column grid system

Who does not know the responsive multi-column layout? A layout that changes the number of columns with the screen size as illustrated above. This was often solved using something like the Bootstrap grid-system, or an own implementation. But, this restricts you to a fixed number of columns for each screen size. If you would have five columns, that would not be possible in a twelve column system. Besides, you have to determine for each element the column span on different screen sizes.

If you have many grids, your CSS or HTML does not scale well. Luckily we have CSS grids these days. With CSS grids we do not define the column span for each element. Instead, we let the browser determine the number of columns on the screen. You can achieve the illustrated scalable layout with the code snippet below. Let's dissect it!

.grid {
  display: grid;
  width: 100%;
  grid-template-columns: repeat(auto-fit, minmax(20rem, 1fr));
}

With repeat() we say to the browser that it needs to repeat its argument. For example, repeat(3, 1fr) would create a layout of three equally sized columns that fill the entire screen. But, our elements almost always have a minimum width. With the 1fr we can break them. With minmax(20rem, 1fr), each column has a minimum width of 20rem, but scales on larger screens.

The magic starts when replacing the fixed number with auto-fit or auto-fill. With both options, we let the browser determine the amount of available columns on the screen. When using auto-fill and minmax(20rem, 1fr) on a screen of 90rem the browser creates four columns. The auto-fit option creates a maximum of four columns in this example. When there are only two elements to put in the grid auto-fit reduces the number of columns to two. This gives you great flexibility in responsive layouts, without using media-queries.

Did you know that you can set a grid-column: span 2 attribute on your elements? When doing so, they will span two columns. So not all elements have to be the same size. The downside is that there will always be at least two columns, and any potential gaps in the grid are not filled.

Two-way card layouts

You often see big card layouts with an image and content next to each other, spanning a big horizontal space. Often they have a fixed ratio between them (e.g. 50%-50%). When reducing the screen size, you don't want these two next, but below each other. The ratio also changed to make better use of the available space. The height of the image is not 50% anymore. The wireframes below visualize this concept.

Does this not sound like a familiar problem? Well, it is. It is almost the same as the auto-scaling grid-layout I already described. There is one small addition. We need to add grid-template-rows: auto 1fr to the grid class example. The auto value accommodates the vertical orientation with a changed ratio. This assumes that the images have a landscape orientation. As there are only two child elements (the image and the content) CSS grids handle the rest.

In CSS grids, row and column definitions are ignored when there are not enough elements. In the above example, when there are only enough elements to fill the first row, the 1fr definition of the second row is ignored.

Conclusion

CSS grids enable you to solve responsive layout issues. There are ways to achieve the above, also without using media-queries. But in most cases they need more CSS to work, making those solutions more difficult to maintain. Especially when combined with fluidity CSS grids (and flex boxes) enable you to create websites that flow with the screen size, and not worry about breakpoints. I mean, they are called break points for a reason, right?

DEV Community: Kevin Pennekamp

A nth-child CSS trick

But why not use X?

How to set it up

What can we do with this trick?

Creating a stacked bar chart using only CSS

The base of the chart

The size of the bars

Stacking the bars

Improve the experience

Wrapping up

Authentication token management

The flow of the solution

The code

Wrapping up

Code stability and interdependencies

The stability rule

Splitting code

Systems, architecture, and patterns

Wrapping up

Demystifying state management

What are state and state management?

Event-driven pattern

Atomic pattern

Reactivity and proxies

Wrapping up

Horizontal centering in CSS

The center layout pattern

CSS grid-based solution

Back to the old school solution

Out with the old, in with new

Wrapping up

Creating an auto-layout algorithm for graphs

Rank all nodes

Optimize the order of the nodes

Determine the position of each node

Wrapping up

Binding CSS and JavaScript with HTML data-attributes

Introducing HTML data-* attributes

Linking JavaScript and CSS

Using data-* for real-life scenarios

State machines

Wrapping up

CSS methodology and architecture

From methodology to framework

detailed look at the framework

Wrapping up

Getting my SvelteKit website on Netlify

Hosting on Netlify

Optimizing the website for SEO

Conclusion

Converting my Gatsby website to SvelteKit

Introducing Svelte and SvelteKit

Working with (S)CSS in SvelteKit

Setting up the markdown file handling

Conclusion

Modern CSS grid solutions to common layout problems

Dynamic centered layout

Responsive multi-column grid system

Two-way card layouts

Conclusion

Introducing HTML `data-*` attributes

Using `data-*` for real-life scenarios