Michael Großklaus

Patterns for Memory Efficient DOM Manipulation with Modern Vanilla JavaScript

2024-08-12T00:00:00Z

https://frontendmasters.com/blog/patterns-for-memory-efficient-dom-manipulation/

`storage` event for localStorage updates

2024-07-16T00:00:00Z

There is a storage event that gets fired when the local storage for a site is updated:

// Listen for local storage changes on our theme key. This lets
// one tab to be notified if the theme is changed in another,
// and update itself accordingly.
window.addEventListener("storage", (e) => {
    if (e.key == LOCAL_STORAGE_KEY_THEME) {
        setThemeFromLocalStorageOrMediaPreference()
    }
})

Source: https://brandur.org/fragments/dark-mode-notes#theme-other-tabs

Content hiding techniques

2024-06-13T00:00:00Z

https://practical-accessibility.today/code/hiding-techniques/ by Sara Soueidan

WCAG simplified

2024-02-12T00:00:00Z

Build and test against WCAG consistently. Understand each success criterion's meaning and how to be accessible: https://thisiswcag.com

Native browser spinner for asynchronous operations

2023-07-17T00:00:00Z

function showLoading(promise) {
	navigation.addEventListener("navigate", (event) => {
		event.intercept({
			scroll: 'manual',
			handler: () => promise,
		})
	}, { once: true });
	
	return navigation.navigate(location.href).finished
}

// show browser loading UI
showLoading(new Promise((r) => setTimeout(r, 1500)));

Source: https://notes.zander.wtf/notes/browser-loading-state/

YAML indicators for multiline strings

2023-02-24T00:00:00Z

There are different indicators to define how multiline strings in YAML files behave.

Block style indicators describe how line breaks behave: With a | (literal style) they are kept as a line break. With a > (folded style) they are converted to a space.

Block chomping indicators describe how line breaks at the end of the string behave: + keeps all of them, - removes them. Without an indicator, one line break will be added to end of the string.

Source: https://yaml-multiline.info

Mobile First versus Shared First CSS

2023-02-18T00:00:00Z

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)

2023-02-04T00:00:00Z

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.

My workflow for storing notes as Markdown files

2022-12-20T00:00:00Z

I have a lot of private notes regarding all kinds of topics: web development, my hobbies, finances, things to buy, work-related tasks, and so on. These notes are probably the most important things I have digitally (besides thousands of pictures) and up until recently they were stored in a PostgreSQL database. This had always been a compromise though. What I actually wanted was to store them in Markdown files on my computer.

I just love Markdown for multiple reasons:

Its simplicity when it comes to writing down any kind of information.
It can easily be converted to HTML.
It can be stored anywhere (and especially locally on my computer).
It is an open standard which is supported by many tools.

The reason I want them to be stored on my computer is independence: I don't want to rely on some 3rd party infrastructure for something such important.

Using Obsidian for working with my notes

What I was missing until now was a tool for macOS that makes it easy to create and read my notes — until I stumbled upon Obsidian. While I am not super fond of its UI (it looks a little bit too techy for me), it did almost everything out of the box the way I wanted it to. Unfortunately it is not open source, but it has a very big amount of community plugins. The small things that were not possible with Obsidian's core plugins, were easy to do with their community plugins: for example keeping the file name in sync with the first heading in a Markdown file (Filename Heading Sync).

Using private and public notes together

Using Obsidian for my private notes would have already been enough for me, but then I thought it would be nice to use it for the notes on this website as well, since they are also written in Markdown. And while Obisidian supports multiple vaults (which is their name for a directory containing Markdown files), I wanted to avoid that as this opens multiple windows — which I don't like at all.

What I did instead was to move my private notes into the repository of this website (which is built with Eleventy), configure Eleventy so that it only uses my public notes and add the directory with the private notes to the .gitignore, so I don't publish them on GitHub.
It does not matter at all to me where on my disk the private notes are stored as Obisidian abstracts that away and opens the vault automatically when restarting the app.

Now I have one application that gives me all my notes, private and public, and a codebase that allows me to publish only the public ones.

Publishing public notes

The way I usually publish notes on this website is through GitHub directly: The GitHub Web UI allows you to create files and commit them in one go. This is super convenient as I don't have to open my editor, create a file, commit and then push it. Instead I bookmarked the URL for creating a new file in the correct directory (https://github.com/mgrsskls/mgrossklaus.de/new/main/notes/webdev in my case), which brings me directly to GitHub's file editor. And as most of the notes I write are Markdown files without any additional files (images for example), using the GitHub Web UI is totally sufficient in most cases.

Pulling notes from the repository

Of course the notes that I published via the GitHub Web UI would not be on my computer without pulling them into my local repository. As doing that how you would usually pull changes would be quite annoying, I created a small app that does that for me: In macOS' Automator app, I created an "Application", chose "Run shell script" and in there I simply use cd to go into the directory of the repository and then run git pull. I can then use Alfred to quickly run the program, which happens completely in the background, so no windows open or anything like that. This is of course does not handle any errors in case pulling fails for example, but in my case I don't really need that.

Syncing with an iOS app

One thing that would be nice to have is being able to maintain those notes on my phone as well. Obsidian offers encrypted synchronisation for that, but as the code is not open source, I don't want to rely on that. There are multiple community plugins that allow you to do that (using services like Dropbox or a CouchDB for example), so I might look into that at some point (probably using a self hosted database).

change event for media queries

2022-12-20T00:00:00Z

There is a change event that can be used to listen to media query changes:

const mediaQuery = window.matchMedia("…");

mediaQuery.addEventListener("change", (e) => {
  …
});

translate attribute

2022-12-18T00:00:00Z

There is a translate attribute telling browsers not to translate the content if using "no": https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/translate

Source: https://twitter.com/spellacy/status/1604193752431661056

Detecting capslock with JavaScript

2022-12-12T00:00:00Z

window.addEventListener("keydown", detectCapsLock);
window.addEventListener("keyup", detectCapsLock);

function detectCapsLock(e) {
  if (e.getModifierState("CapsLock")) {
    // caps lock is on
  } else {
    // caps lock is off
  }
}

Source: https://iamkate.com/code/caps-lock/

Fluid type and size calculator

2022-11-18T00:00:00Z

https://utopia.fyi

Web Share API

2022-11-15T00:00:00Z

There is an API to trigger the native sharing function of the OS: https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API

Accessibility testing guide

2022-11-11T00:00:00Z

https://github.com/alphagov/wcag-primer/wiki "outlines some approaches for testing websites and applications against the Web Content Accessibility Guidelines (WCAG) 2.1 AA Level".

Modals are not dialogs

2022-11-09T00:00:00Z

Modals are not another noun for dialogs, but an adjective describing certain types of dialogs:

Basically, when a modal component is open, it is the only thing that is not inert. Only the modal content can be interacted rest with, the rest of the page or application is made inert. Inert content is content that users cannot interact with. It is only really there visually, but you cannot Tab to it, click it, scroll it or access the content via assistive technologies.

— Hidde de Vries

Source: https://hidde.blog/dialog-modal-popover-differences/

Making the subtree of a hidden element visible

2022-11-07T00:00:00Z

If an element is hidden via visibility: hidden, its subtree can be made visible by using visibility: visible:

parent {
  visibility: hidden;
}

child {
  visibility: visible;
}

Source: https://www.scottohara.me/blog/2022/11/07/responsive-accessibility.html

Gradient border

2022-11-07T00:00:00Z

Without rounded corners:

border: solid 0.25rem;
border-image: linear-gradient(to bottom right, darkmagenta, aquamarine);

With rounded corners:

border: solid 0.25rem transparent;
background:
  linear-gradient(white, white) padding-box, 
  linear-gradient(to bottom right, darkmagenta, aquamarine) border-box;

Drawback: You need to set a solid color as background, so it cannot be transparent.

Source: https://twitter.com/argyleink/status/1589657198766231552

Accessible color combinations

2022-10-28T00:00:00Z

https://randoma11y.com creates random accessible color combinations.

Better error messages

2022-10-18T00:00:00Z

Source: https://wix-ux.com/when-life-gives-you-lemons-write-better-error-messages-46c5223e1a2f

Minimal social markup

2022-07-22T00:00:00Z

<meta name=twitter:card content=summary_large_image>
<meta property=og:title content="This is a test title">
<meta property="og:description" name="description" content="This is a test description.">
<meta property="og:image" content="https://hell.meiert.org/core/png/test.png">

Source: https://meiert.com/en/blog/minimal-social-markup/

Lite youtube embed

2022-03-09T00:00:00Z

Youtube embeds are not very performant, so here is a web component with focus on performance: https://github.com/paulirish/lite-youtube-embed

Accessibility outline bookmarklet

2022-02-08T00:00:00Z

Quickly analyze landmarks, headings and links of a website: https://xi.github.io/a11y-outline/

My favourite bookmarklet.

SVGs in high contrast mode

2022-02-06T00:00:00Z

@media (forced-colors: active) {
  svg {
    fill: CanvasText;
  }

  a svg {
    fill: LinkText;
  }
}

Dynamic search results for screen readers

2022-02-06T00:00:00Z

This to consider for screen readers when implementing dynamic search results: https://www.scottohara.me/blog/2022/02/05/dynamic-results.html

Order in the head

2021-09-22T00:00:00Z

<meta />
<title>
preconnect
<script async></script>
CSS with @imports
sync JS
sync CSS
preload
<script defer></script>
prefetch / prerender
everything else (SEO, icons, open graph)

Source: https://twitter.com/smashingmag/status/1440697011985018881

Remove blank space from SVGs

2021-04-23T00:00:00Z

SVG Crop: https://svgcrop.com

An alt decision tree

2021-04-16T00:00:00Z

A few questions to help you decide if an image should have an alt value or not: https://www.w3.org/WAI/tutorials/images/decision-tree/

inputmode attribute

2021-03-18T00:00:00Z

The inputmode attribute allows to define the type of keyboard which is shown when focusing an input.

Values:

none
text
decimal
numeric
tel
search
email
url

Source: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode

Numbers with same width

2021-03-01T00:00:00Z

With the following CSS we can make sure that numbers are all rendered using the same width (similar to monospaced fonts):

font-variant-numeric: tabular-nums;

This can be helpful for example for tables or when displaying prices below each other.

JavaScript loading priorities in Chrome

2021-03-01T00:00:00Z

Table about loading priorities of render blocking, async, defer, prefetched etc scripts in Chrome: https://addyosmani.com/blog/script-priorities/

enterkeyhint attribute

2021-03-01T00:00:00Z

The enterkeyhint content attribute is an attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards.

Values:

enter
done
go
next
previous
search
send

Source: https://html.spec.whatwg.org/multipage/interaction.html#input-modalities:-the-enterkeyhint-attribute

Animation principles

2021-03-01T00:00:00Z

The following principles are valid for all kinds of animations:

Appearing: ease-out, longer animation
Disappearing: ease-in, shorter animation
Moving: ease-in-out
Long distance / big screen: longer animation
Short distance / small screen: shorter animation

When fading in list items, that means multiple items:

overlapping, not one after, not at the same time
vertical: top to bottom
grid: top left to bottom right

Source: https://uxdesign.cc/the-ultimate-guide-to-proper-use-of-animation-in-ux-10bd98614fa9

Language-specific quotation marks

2021-02-28T00:00:00Z

blockquote::before {
  content: open-quote;
}

blockquote::after {
  content: close-quote;
}

Source: https://www.stefanjudis.com/today-i-learned/how-to-use-language-dependent-quotes-in-css/

Print in landscape

2021-02-16T00:00:00Z

@media print {
  @page {
    size: landscape;
  }
}

At the time of the tweet, it worked in blink only.

Source: https://twitter.com/mmatuzo/status/1361698055385399304

Accessibility checklist

2021-02-08T00:00:00Z

https://www.magentaa11y.com/web/ lets you create a comprehensive testing guide for all elements on your page.

Minimal favicon markup

2020-12-25T00:00:00Z

<link rel="icon" href="/favicon.ico" sizes="any"><!-- 32×32 -->
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png"><!-- 180×180 -->
<link rel="manifest" href="/manifest.webmanifest">

// manifest.webmanifest
{
  "icons": [
    { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" },
    { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" }
  ]
}

Source: https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs

CSS Grid tiles

2020-12-22T00:00:00Z

I can never remember this snippet:

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

This will create equally sized columns, where 20rem is the minimum width of the columns. When they would become smaller than this, the last entry in a row moves to the next row.

We use min(100%, 20rem) to avoid overflow when the container is smaller than 20rem.

Utility class for hiding elements visually

2020-12-15T00:00:00Z

Hiding elements visually, but keeping them for screen readers:

.u-hiddenVisually {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  border: 0;
  padding: 0;
  white-space: nowrap;
  clip-path: inset(100%);
  clip: rect(0 0 0 0);
  overflow: hidden;
}

My by far most used utility class.

Source: https://allyjs.io/tutorials/hiding-elements.html#2017-edition-of-visuallyhidden

URL encoder for SVG

2020-12-15T00:00:00Z

If you want to use an inline SVG in a CSS file: https://yoksel.github.io/url-encoder/

System fonts

2020-12-15T00:00:00Z

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica,
  Arial, sans-serif;

font: 1rem/1.2 BlinkMacSystemFont, -apple-system, "Segoe UI", Roboto, Helvetica,
  Arial, sans-serif;

The shorthand version cannot start with -apple-system!

Source: https://booking.design/implementing-system-fonts-on-booking-com-a-lesson-learned-bdc984df627f

Google Fonts Downloader

2020-12-15T00:00:00Z

Google Fonts can and should be served locally instead of from google. This tool can be used to download the font files: https://google-webfonts-helper.herokuapp.com/fonts

Reducing the file size of open source fonts

2020-01-12T00:00:00Z

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.

How to organize components

2019-08-21T00:00:00Z

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 miyagi. It is a small node module that can be used to develop your components in isolation, no matter how you organize them.

It does not always need to be the hippest code

2019-08-12T00:00:00Z

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.