DEV Community: Michael Großklaus

Mobile First versus Shared First CSS

Michael Großklaus — Sat, 18 Feb 2023 00:00:00 +0000

In this post I want to give a short example why there is in my opinion a better way than using a Mobile First approach when writing CSS. Please note that for simplification I will refer to viewports as well as media queries, but the same concept also applies to anything that can be controlled by media and container queries.

Mobile First

When Responsive Web Design and media queries became a thing, it was considered best practice to follow a Mobile First approach when writing CSS for a website. Besides being aligned with the conceptual Mobile First approach (where you — in simple terms — first make sure that your content and its structure works on small devices), this also had the advantage to support browsers that did not yet support media queries. For those you got the mobile view.

An example for that would be something like this simple page layout:

<body>
    <main></main>
    <aside></aside>
</body>

body {
    display: flex;
    flex-direction: column;
    gap: 1rem;
}

/* medium */
@media (min-width: 40em) {
    body {
        gap: 2rem;
    }
}

/* large */
@media (min-width: 60em) {
    body {
        flex-direction: row;
        gap: 3rem;
    }

    main {
        flex: 3;
    }

    aside {
        flex: 1;
    }
}

In this case we first use flex with columns, so that the <main> and <aside> elements are below each other. This could be done without defining any CSS at all as they are both block elements, which would be rendered in a column anyway. But using flex allows us to use gap which is unfortunately not (yet) supported on block elements.

In the first media query we increase this gap for medium viewports.

In the second media query we then set flex-direction to its initial value row , so the <main> and <aside> elements are horizontally aligned. We also redeclare the gap. Additionally we set flex values for our two elements, so that main takes more space than aside.

If you look at the media query for medium viewports, you also notice that the media query only uses min-width, so it is basically open ended and has no limit in terms of width. As you can see all we do in there is defining the gap (for medium viewports), which we then overwrite again in the next media query (for large viewports).

Besides the fact that it is not necessary anymore to go for a Mobile First approach when it comes to CSS since media queries have been supported in all major browsers for a long time now, this approach also comes with two downsides:

Error prone: If we want to add or change CSS for small or medium viewports, this CSS would bleed up, i.e. affecting larger viewports. This means we might introduce a bug, if we do not undo our changes for larger viewports. So, writing CSS code this way is very error-prone because changes might have unintended side-effects.
Difficult to inspect: Inspecting why something behaves a certain way becomes more difficult. You end up with properties being overwritten, sometimes even multiple times. This can be seen when looking at the devtools where you would have lots of striked through properties. This is a screenshot of the devtools for large viewports:

This is of course a short example, but imagine how this quickly escalates in an actual, more complex website. Seeing lots of overwritten properties like this is usually a good indicator that the CSS is prone to errors and might be worth a refactoring.

Shared First

So, how can we change our CSS to avoid these issues? What works really well for me is an approach that I would call, for lack of a better name, Shared First.

In this approach you only define CSS outside of media queries which should be shared by viewport sizes and everything that should only be applied for certain viewport sizes goes into a media query that matches only that viewport size:

body {
    display: flex;
}

/* small + medium */
@media (max-width: 59.96875em) {
    body {
        flex-direction: column;
    }
}

/* small */
@media (max-width: 39.96875em) {
    body {
        gap: 1rem;
    }
}

/* medium */
@media (min-width: 40em) and (max-width: 59.96875em) {
    body {
        gap: 2rem;
    }
}

/* large */
@media (min-width: 60em) {
    body {
        gap: 3rem;
    }

    main {
        flex: 3;
    }

    aside {
        flex: 1;
    }
}

Let's break this down:

Outside of all media queries, we first define everything, that is shared: in our case, all we do is turning <body> into a flex element as this is the only thing that is shared throughout all viewport sizes.
The first media queries covers small and medium viewports. In there all we define is that for these sizes we want to use a column layout. This makes sure that we later do not have to revert this.
The gap is then defined in each media query: We explicitely define it once for small, once for medium and once for large viewports. This allows us to change the values without accidentally affecting other viewport sizes.

Admittedly, these are a few more lines than in the Mobile First approach, but shorter code does not always mean better code. Instead shorter code might be harder to understand and more difficult to maintain.

Why does this work better?

First of all, by declaring CSS only for the resolutions we actually need it, we avoid side effects.
Let's say on small viewports we now want to change the font size, we can do that by adding it to the media query for small viewports without any side effects. In the Mobile First approach this would have caused a regression if we did not revert that definition for larger viewports.

Second of all, inspecting this is much easier. This is how devtools would look for our Shared First example for large viewports:

Much cleaner, isn't it?

Summary

Using a Mobile First approach when writing CSS is error prone and often leads to unintended side effects. It is also more difficult to investigate what is happening in the CSS.
This can be avoided using a Shared First approach where only the CSS, that should be applied for all viewport sizes, is defined outside of media queries. The CSS, that should only be applied for certain viewport sizes, will go into media queries that are defined to match only those exact viewport sizes.

Disclaimer

I know that there might be shorter and easier ways to write this layout example using custom properties, but this is simply an example to illustrate the issues and benefits.

Implementing a theme toggle with HTML and CSS only (almost)

Michael Großklaus — Sat, 04 Feb 2023 00:00:00 +0000

Implementing a light and dark theme based on the user's OS settings has become quite popular. But often users just want their OS to be dark, while they prefer reading a website with a light background, for example. It is therefore considered good practice to offer a theme toggle, that allows the user to change the theme of the website regardless of their OS theme.

To implement that, we would usually have some HTML like the following:

<form>
  <fieldset>
    <legend>Color scheme</legend>
    <input type="radio" name="theme" value="auto" id="theme-auto" checked />
    <label for="theme-auto">auto</label>
    <input type="radio" name="theme" value="light" id="theme-light" />
    <label for="theme-light">light</label>
    <input type="radio" name="theme" value="dark" id="theme-dark" />
    <label for="theme-dark">dark</label>
  </fieldset>
</form>

Using JavaScript we would then listen to the change event of those inputs and add a class to the html or body node. Based on that class, we would style the page accordingly:

.theme-dark {
  …
}

Using the :has() pseudo-class, we can be implement this theme toggle without JavaScript. Instead of using a class, we can do this:

html:has([name="theme"][value="dark"]:checked) {
  …
}

To make sure that the user does not have to change the theme on every page visit, we should of course still use some JavaScript:

We save the selection in the localStorage, but then — instead of adding a theme class — we simply set the checked attribute of the correct input in the theme toggle. Ideally we do this in an inline script (as opposed to some asynchronously fetched script) to avoid any possible layout flickering.

Complete example

HTML

<form>
  <fieldset class="ThemeToggle">
    <legend class="ThemeToggle-title">Color scheme</legend>
    <input type="radio" name="theme" value="auto" id="theme-auto" checked />
    <label for="theme-auto">auto</label>
    <input type="radio" name="theme" value="light" id="theme-light" />
    <label for="theme-light">light</label>
    <input type="radio" name="theme" value="dark" id="theme-dark" />
    <label for="theme-dark">dark</label>    
  </fieldset>
</form>

<script>
  function renderTheme(theme) {
    if (!["auto", "light", "dark"].includes(theme)) return; 

    const checkedInput = document.getElementById(`theme-${theme}`);

    if (checkedInput) {
      checkedInput.checked = true;
    }
  }

  renderTheme(localStorage.theme);
</script>

CSS

html {
  … /* styling for light theme */
}

html:has([name="theme"][value="light"]:checked) {
  … /* styling for light theme */
}

@media (prefers-color-scheme: dark) {
  html {
    … /* styling for dark theme */
  }
}

html:has([name="theme"][value="dark"]:checked) {
  … /* styling for dark theme */
}

JavaScript

document.querySelectorAll(".ThemeToggle input").forEach((input) => {
  input.addEventListener("change", onThemeChange);
});

function onThemeChange({ target }) {
  const { value } = target;
  renderTheme(value);
  saveTheme(value);
}

function saveTheme(theme) {
  if (theme === "auto") {
    localStorage.removeItem("theme");
  } else {
    localStorage.setItem("theme", theme);   
  }
}

Browser support

At the time of writing this (04.02.2023), :has() is supported by all major browsers except for Firefox.

To make sure this also works in Firefox, you can simply combine this approach with the class-based approach mentioned earlier — and throw it away as soon as Firefox turns green! :) (:has() on caniuse.com).

Important

Just be aware that you cannot combine both selectors as :has() is invalid in Firefox. This means that the following snippet would not work at all in Firefox:

.theme-dark,html:has([name="theme"][value="dark"]:checked) {
  … /* styling for dark theme */
}

Instead you have to use the selectors separately:

.theme-dark {
  … /* styling for dark theme */
}

html:has([name="theme"][value="dark"]:checked) {
  … /* styling for dark theme */
}

Optimizing CSS for theme toggles

Since it can be a bit cumbersome to write CSS for theme toggles as you would have to duplicate some code in your CSS,Fynn wrote down a nice approach using custom properties, which I highly recommend: CSS Custom Property toggles for themes.

From design to code

Michael Großklaus — Tue, 13 Apr 2021 07:49:40 +0000

Since 2020, we at Factorial do not only offer web development, but also conception and design for all kinds of web projects. And while in the past designing and developing websites has usually been a quite separate process, there are nowadays powerful tools for cooperation between designers and developers. At Factorial we try to make use of these tools as much as possible.

Designing in Figma

Our designers work with Figma, a web-based design tool developed for easy collaboration with developers. We will show later how we actually make use of that, but for now let us have a look at how we structure the projects.

Usually we create five so called “Pages” in Figma:

Design Tokens
Elements
Patterns
Template components
Templates

Design Tokens

Design tokens are a set of styles — colors, typography, size and effect variables that are used across the product — to create a consistent and simple design language.

On the Design Tokens page, we create four different art boards: Colors, Typography, Spacings, Other

Colors can contain colors for typography but also decorational colors. It is important for us to separate these two to make sure that certain colors should only be used for certain things. E.g. a light grey might be good for background or an outline, but not good for typography as the contrast ratio could fail, especially for visually impaired users.

Spacings contain a list of pixel based spacing values (which will later be converted to rem in CSS), usually starting at 4 and containing not more than 8-10 values.

Typography lists all different types of text styles: headlines, copy, highlighted text, links and so on.

On Other we define values for elevation, borders, radiuses or certain effect styles needed for i.e. hover effects or overlays.

Elements, Patterns, Template Components and Templates

The pages Elements, Patterns, Template Components and Templates are where the actual designs are located.

On Elements we have small components which can be reused everywhere. These are usually components like buttons, icons, form elements, images, etc..

Patterns are combinations of elements, but not only. They are rather complex components like an image gallery, rich text, a slide show and so on. These components can later be picked by the editors of a CMS to compose the content of a website, e.g. using Drupal’s Layout Builder.

Template components are the single parts of a template: header, footer, navigation, search results, sidebar etc.. These elements can not be picked by editors, but are instead a fixed part of templates.

Templates bring everything together: They connect template components and patterns and represent completes pages like a homepage, product page, search results, etc..

Importing design tokens via Figma API

When naming pages, art boards and tokens in Figma, it is very important that we follow a certain structure and naming convention. Not only does that make communication and reusability easier, it also allows us to use the Figma API to import our design tokens and components directly into our projects.

Our frontend stack, which is part of every new project, contains a small script, which lets us do exactly that. When executing it, it will use the Figma API to connect to our Figma file, receive a JSON response containing all the necessary information about the designs and then create

a tokens.css file, which contains CSS custom properties based on the Design Tokens page in our figma file,
empty components based on the other four pages.

The custom properties are named accordingly to the design tokens in the Figma file. This makes sure that designers and developers talk about the same things and it simply makes it easier to remember how things are named. Since this file is auto-generated, it should never be changed manually. As soon as we run the import again, this file would be overwritten.

For elements, patterns, template components and templates, the script creates empty components in the same hierarchy. If the Figma file e.g. contains a button component on the Elements artboard, it would create

elements
└── button
    ├── button.css
    ├── button.twig
    ├── mocks.yaml
    └── schema.yaml

It would only do that if this component does not exist yet to avoid overwriting components, which have already been implemented.

While the button.css and button.twig (twig is template language of our choice) are part of the actual component, the mocks.yaml and schema.yaml are important for collaboration with backend developers and for our component library.

Developing in miyagi

After having used Pattern Lab for many years, it met our requirements as a component library less and less. It is a proven, well-working tool, but it started feeling too heavy and too slow for us. We also had increasing needs, which our component library should fulfil and Pattern Lab was simply not able to do that. After evaluating lots of different tools and not being able to find just one tool which would be able to deliver everything we need, I ended up creating a tool myself to serve that purpose. It is called miyagi.

miyagi is a node module, using an express server and can basically fit to any project structure you have. You can name your folders and components any way you want, nest them as deep as you want, use (almost) any kind of JavaScript templating language and all it needs in your project is one configuration file (it actually even works without a configuration file by trying to guess your template language, but you need to follow a certain naming convention for your folders and components then). This allows us to use it in different kinds of projects while keeping the project structure completely independent from our component library. If we ever want to use a different one, all we need to do is remove the configuration file.

Design tokens

When you open the start page of a miyagi instance, you will get a representation of our design tokens: miyagi is able to parse our CSS files, look for custom properties with a certain naming (which we get out of the box thanks to our token importer) and create a nice overview of all design tokens we have in a project.

Customer theme

miyagi can also be styled in the CI of our customers: fonts, colors, a logo and basically any CSS can be added to give the customer the feeling that it is their component library.

The schema files

The schema files are JSON schema files. We use them to agree on a certain data structure for a component, to make sure that the provided data by a backend service actually fits to that component. But they also allow our designers to come up with certain restrictions, e.g. a given text should only be 200 characters long etc..

While these schema files are independent from a component library, they are still used by miyagi to validate the mock data: If the given mock data for a component does not fit to the given JSON schema, it will render an error.

The mock files

One aspect of component libraries is usually that they allow encapsulated and indepenent development of components. This means that frontend developers can build a component without having to wait for a backend service, which provides them data or an environment to render this component.
To do that in miyagi, we can create mock files to provide dummy data for our components. This can be static using yaml or json, but you can also use JavaScript files, which asynchronously export data coming from some API, for example. That way we can have many different variants of a component to make sure that the components always work, no matter how the data which is passed to the component looks like.

Based on these mock files, miyagi creates a separate view for every variant. We use these views also for our visual regression tests.

Testing for visual regressions using our component library

To make sure that we do not accidentally create visual regressions, we use BackstopJS to test our components (including all elements, patterns, template components and templates) for exactly that.

The way this works is that when creating a pull request in our git repository, we first create a static build of our component library (which will later be deployed to a dedicated instance, so everyone can have access to that: designers, developers, project managers, the client, …) and then use these static build files to compare them with the previous ones (which are checked in to the git repository).
That means we have a direct coupling between our component library and our visual regression tests and are not depending on some third party services: there won’t be any downtime and nothing leaves our servers.

Starting projects with the Frontend Starter Kit

Last but not least, we tried to make things even easier, even more consistent and therefore even better and stable.

Since websites do quite often consist out of the same (or at least very similar) components, we came up with the Frontend Starter Kit, which is basically made of all of the above:

a Figma file which contains accessible colors, typography, components like form elements and so on
web components for form elements and other recurring components, which are published as node modules
a Drupal theme providing form elements and other types of components
all developed and tested for visual regressions using miyagi

This Frontend Starter Kit works for many different types of projects and since we publish the components as node modules, we can even use them in Vue projects.

Overall this allows us to have a standardized, well-proven and consistent base for all our projects, avoiding the “stupid” work which every project contains and letting us concentrate on the rest.

Reducing the file size of open source fonts

Michael Großklaus — Sun, 12 Jan 2020 00:00:00 +0000

I was recently working on the relaunch of my website and wanted to include the open source font Inter. Unfortunately, even the woff2 versions of each different font style were at least 100kb large. As I wanted to use three font styles, this was, of course, way too much.

Fortunately, I knew that it is possible to reduce the file size by only using certain characters. After a quick search I stumbled upon FontForge, which allows you to edit all sorts of things in open source fonts (I honestly do not have a clue what most of them are). I opened the font files and saw that all kinds of characters (romanian, greek, kyrillic and other letters, characters for spacings, mathematical characters and so on) were included. Since my website does not have any user generated content, I knew pretty well what kind of characters I would need. Especially for bold and italic font styles, the amount of necessary characters is very limited. That way I was able to remove most of the characters and decrease the total size of all font files from 314kb to 39kb.

The steps to do that are the following:

Open a font file via File → Open
Go to Element → Font Info (opens a new window) → Unicode Ranges
Select an entry in the list
In the other window deselect the characters you want to keep and remove the selected characters via Encoding → Detach & Remove Glyhphs…
Repeat that for every entry in the Unicode Ranges list
Create a new font file via File → Generate Fonts…

Admittedly, the UX could be a bit better and depending on your font files, this can be quite time-consuming. Nevertheless, it is fairly easy with FontForge to remove characters from a font file and the results are definitely worth it.

Note: At the time of writing this, the security restrictions on macOS Catalina do not allow you to open font files from your “Downloads”, “Documents” and “Desktop” folders. Move the font files in any other folder if FontForge says “Unauthorized / Operation not permitted”. See also this issue on GitHub.

My 2019

Michael Großklaus — Fri, 03 Jan 2020 00:00:00 +0000

2019 has been a quite different year for me. Since I started freelancing in 2011, I only worked on client projects the whole time (except for a few weeks of vacation every year). But as my son was born last year, I wanted to work a lot less. Besides going on parental leave (I took three months, another one will follow this year), I decided to not actively look for work. If no requests from potential clients came in, that would be fine. Instead, I would just enjoy slowing down, spending time with my family and from time to time working on private projects.

Private projects

That way it also happened that I published my first node modules. After having used PatternLab often, I wanted to create something similar, but more lightweight and better fitting to my needs. I finally started looking into NodeJS and eventually released headman. It is a component development tool based on Express and Consolidate.js that allows you to develop your components in isolation and render them using dummy data. For me the latter is very practical as I often work on projects where backend and frontend development happens time-delayed.

Two other node modules I published were typing-effect and text-truncation.

The download numbers for all my node modules are low, but for me they all fulfill certain use cases that – as far as I can tell – haven’t been solved by any other node modules. And by far the most positive aspect in developing them was that it helped me a lot digging into NodeJS and to better understand npm.

Client work

Besides that I worked on a few clients projects:

I helped Factorial develop the new (but unfortunately not yet released) checkout process for Stellenwerk, a job portal for students. It uses Drupal and PatternLab in the background.
Also together with Factorial as well as the developers of G+J, I worked on the technical base for their new paid content websites. We wanted to make development as fast and convenient as possible and were able to implement a solution that required nothing else then starting a Koa server, no build tools and so on required.
For Hannes Hawaii Tours, I worked on a booking system together with Patrick Schnetger. The challenge was that the booking system was supposed to be sold as a white label solution as well, allowing the clients to configure the booking process in a quite open way. That demanded a lot of thinking about the technical architecture. Using Ruby on Rails and being just one backend and one frontend developer allowed me and Patrick to make really fast progress while at the same time being able to easily make bigger changes to the architecture when requirements changed. I still really enjoy working with Ruby on Rails as I like the tight coupling between frontend and backend (even though the current development rather goes in the other direction).
I worked on an interesting small project for Fork Unstable Media. Unfortunately, I had to sign an NDA for it.
After having worked for the german LinkedIn competitor XING already around 2015, they asked me to support them again at the end of the year. Having never really worked with React before, I was happy they trusted me to be able to dig into it quickly. I helped them improve their design system which is based on Hops and uses React for templating. As the design system is for now only for internal use, it was refreshing to be able to use all sorts of new CSS features, not having to think about older browsers.

Having worked with different technologies in 2019, I hope I can continue to do so in 2020. As we all know it is difficult to catch up with all the new frontend developments, especially when you can usually only do that in your spare time. Having a client trusting me to do so while working for them, was one of the most rewarding experiences in my freelance career so far.

What is next

I will try to blog more and try to use my blog as a collection of useful technologies, patterns, tips, …
Life with a family in a popular city is expensive, so I will increase my working time again while trying to miss as little as possible from the huge (metaphorical and real) steps my son makes every day.

What can we do about climate change?

Michael Großklaus — Thu, 10 Oct 2019 18:30:00 +0000

When following discussions in the web development community, you can read a lot about topics like inclusion, diversity, accessibility and so on. While all these topics are important and should not be missed, I barely read about a topic that concerns me as no other: climate change.

Thinking about why this is, it seems that climate change has nothing directly to do with the web development community. We are building websites, most of us from 9 to 5, some as freelancers, some as open source contributors, others engaging actively in the community.

How we deal with the climate change seems more of a private topic though. Everyone has to decide for themselves what they can do: eating less meat, flying less, taking the bike instead of the car, etc.

But I think this is only partly true.

Around two years ago, my client, their client and I had a kickoff meeting in London. My client and I flew there from Hamburg in the morning and back in the evening. There were around 15 people, but only three or four were actually talking. Yes, it is always good to get to know everyone in person, but there was nothing happening that required physical presence.

I also see more and more conferences popping up everywhere. With every new technology, every new framework lots of conferences around that specific topic are organized. Developers from the whole world come together, meet people they maybe only know from chatting online, making new friends, going to workshops.

I know that many of us love these events outside of our every day life. And I know that you can not forbid people to fly around the world.

But I really think that we need to think about if this is actually necessary.

There are thousands of articles describing what is going to happen if we fail in stopping the earth from heating up. The earth in 20, 30, 50 or 100 years would probably be completely different from what it looks like now. All our new technologies and our knowledge might not mean anything at all anymore as instead we might fight with our neighbours about food, water and a place to live.

Is it worth it?

Again – I know that meeting someone digitally is not the same as meeting someone in person. But I think that whenever it is possible, it is our duty to do so. For too long we were living at the expense of future generations to just continue like this.

You might say that the web development community is too small, that we do not have enough power or that not getting on a plane to fly to the next conference is not going to change anything.

This is true. And not.

Us alone not flying anymore does not change anything, yes. But if everyone thinks that way, we will definitely lose. Do you want to continue as we do just because others do not care? I do not. I do not want to feel guilty. I do not want to feel that I have not given everything just because other people do not care.

It is my strong belief that we will only be able to stop the climate change with renunciation and technology.

And as no other industry in the world, we are able to build tools, that connect people in the whole world. We can stop jumping on planes and instead use the tools we have. Improve them. Build new ones. Spread them.

How to organize components

Michael Großklaus — Wed, 21 Aug 2019 00:00:00 +0000

Probably the most popular way of organizing your components is Atomic Design which was introduced by Brad Frost. I recently talked to a client of mine who said that they were succesfully using this methodology in all their projects and that it works really well for them. We had a short discussion about it as I was using it for a little bit as well, but was realizing pretty quickly that it would just not work for me. One reason for that is the following example: let’s say you have two atoms; a button and an icon. If a button could also have an icon included, you would include an atom in another atom. While you could of course do that, it simply feels wrong to me (there are also no atoms in atoms in the nature, are there?).

That is just one example for why I came up with my own way of organizing my components.

Of course, this is an ongoing process and every project is different, but I basically follow these rules:

Which directories should I use?

templates - The actual page templates.
content - Content components, which can be picked by the editors to fill pages with content.
components - All the remaining components that should not be used directly by editors (usually something like icons, buttons, etc.).

When should I create a new component?

When using code in multiple components. As soon as you use the same code (or slight variations of it) multiple times, make a component out of it.
When rendering entries of a collection. If you render a collection, put the code for the entries (e.g. a teaser in a teaser list) in a separate component.
When your component becomes too complex. This is a rather vague rule, but as soon as you have the feeling that your component becomes too complex, move logical parts into their own component.

While the first rule is essential to avoid code duplication, the second and third rule are basically only for reducing the complexity of a component. In that case, I would call the components “sub components”.

Where should I put my sub components?

In a directory in its parent component. As you are not using these components anywhere else, you can “scope” them by putting them in a sub directory of the actual component. This couples them tightly together and you can find all the code where you expect it.

What about components that are only used for templates?

Components, that are used by multiple templates and only by templates (e.g. header, footer, navigation), live in a subdirectory called _includes/ in the templates/ directory. I prefix the name of this directory with _ to show that it is some sort of a helper directory and not a template.

Example

The structure for an example project could look like this:

├── components
│ ├── button
│ ├── icon
│ ├── image
│ ├── input
│ └── video
│
├── content
│ ├── cta
│ ├── gallery
│ │ ├── thumbnails
│ │ │ └── thumbnail
│ │ └── view
│ ├── rte
│ └── teaser-list
│ └── teaser
│
└── templates
    ├── _includes
    │ ├── footer
    │ ├── header
    │ └── navigation
    ├── homepage
    ├── standard
    └── checkout

Again, this is nothing static and can be adapted for every project. Especially having a directory called content with components that can be picked by editors, makes of course only sense when there is actually a CMS behind the scenes.

If you are looking for a component library that plays well together with what I described in this post, feel free to check out headman. It is a small node module that can be used to develop your components in isolation, no matter how you organize them.

An easier way to use relative units

Michael Großklaus — Thu, 15 Aug 2019 00:00:00 +0000

Browsers nowadays perfectly zoom in and out when using cmd-+ and cmd--. Because of this, developers sometimes think that using relative units is actually not necessary. But as zooming that way only affects the current website, browsers also have a setting to change the default font size of the browser. Unfortunately, this has no effect when using absolute units. That is why using relative units is important.

As in the beginning of my developer career it was still completely normal to use px for everything and getting Photoshop layouts with pixel measurements, I still think in pixels when developing. Of course, there are tools that help you with that: you can e.g. use px in your code base which becomes converted to rem when using a post- or pre-processor.

But as it is better to not rely on tooling, I prefer to use one of my all-time favourite css tricks:

html {
  font-size: 62.5%;
}

62.5% equals 10px, as the default font size of a browser is 16px (16 * 0.625 = 10).

Now you can use rem and your values are the same as your pixel values, the decimal separator just moved one digit to the left:

body {
  font-size: 1.6rem; /* 16px */
}

.wrapper {
  max-width: 72rem; /* 720px */
}

Don’t forget to explicitely set font-size on the body now, as 10px is too small for a default value.

Note: I sometimes see developers using html: { font-size: 10px; } to achieve the same, but this does not fix the zooming problem.

It does not always need to be the hippest code

Michael Großklaus — Mon, 12 Aug 2019 00:00:00 +0000

One reason frontend development never becomes boring is the fact that the available technologies evolve rapidly. Browser vendors publish new features every few weeks, which makes it hard to stay up-to-date. At the same time it also makes development much easier as as a lot of functionality gets introduced by the new browser versions.

When working on a project, it is now completely normal for me to implement its layout or features with Flexbox – or in some (still rare) cases with CSS Grid. Both make implementing most layouts much easier.

The last project I worked on seemed to be such a case. One main element of it was a teaser list, which was supposed to look roughly like this:

The important part here was that the vertical space between the teasers was the same as the horizontal space.

A colleague of mine started implementing it using CSS Grid, splitting it up in 12 columns, repeating rows, spanning content over multiple columns etc.. It worked well and using CSS Grid seemed like an obvious choice, but unfortunately we realized that the Internet Explorer (yes, we still had to support it) didn’t support some of the CSS Grid features that were used. When my colleague went on holidays, I took over and tried to adapt the Grid solution, so that the IE would support it and we didn’t have to throw away all the code. I realized though that it just wouldn’t work, so I changed the code to use Flexbox which was actually not a big change. The main principle was the same: I just had to use some other attributes, doing minor tweaks and was done pretty quickly.

Later on I realized that the horizontal space between the teasers was not correct yet. In my solution, the small teasers (2, 3, 5 and 6) were always aligned to the bottom of the big teasers (1 and 4). I had then pulled up teaser 2 and 5 with negative margins to put them in the right position. It looked perfect, but only due to some bad dummy data and other coincidences, making all the text boxes have the same height. Of course their height needed to be flexible though. So, with more realistic data it looked somewhat like this:

As you can see here, the space between teaser 1 and 2 became too big because the text box in teaser 1 pushed down everything.

My next idea was to take the text boxes of teaser 1 and 4 out of the flow, using position: absolute to align it at the bottom of the big image and then pulling it down by a fixed value. That way all small teasers would align to the bottom of the big images and I could pull down the teaser 3 and 6 by the same value I pulled down the text boxes of teaser 1 and 4.

The designer was fine with this solution, but the variable height of the text boxes in teaser 1 and 4 was a problem again as they could theoratically become higher and higher. Especially on smaller viewports, the text box becomes too high quickly as it is narrower and expands to the top:

I thought about it quite a bit and was sure that there is no way to implement this layout with flexbox.

Since there must be a way though, I was then trying to find another way to take the text boxes out of the elements flow – until float came into my mind.

Having it used for many years for almost every layout I implemented, I had now almost completely forgotten it. Trying around a little bit, it took just a few minutes to actually have the complete solution. The steps for that roughly were:

Float the text boxes of teaser 1 to the right. That way the text box doesn’t have any impact on the height of its containing teaser and the following teaser is automatically aligned to the bottom of the image (technically correct: to the bottom of the teaser).
Now set float: left on teaser 2 and float: right on teaser 3. That way teaser 3 is placed next to the teaser 2. But most importantly, it aligns to the bottom of the text box in teaser 1. That is because a floated element still reserves space (unlike elements with position: absolute), it just doesn’t influence its containers height.
Now I could do the same with the teasers 4, 5 and 6, but inverted.

That was it. A modern looking layout with quite oldschool code, completely supported in all browsers without any polyfills or vendor prefixes.

You can find a basic implementation here:

See the Pen float layout by Michael Groklaus (@mgrsskls) on CodePen.

Implementing this made me realize that there are so many things happening in the frontend world, that we almost forget about some of the most basic features. It is important to be aware of new developments as they can make a developers life much easier. But while new technologies often still need tooling around them, knowing the basics is crucial to write accessible, simple and widely supported code.