Skip to main
a head full of music on repeat by
Timo Mämecke
Skip to content
Jump to navigation

6 posts in Web Dev

· 12 minute read

A Better Button Component with Composition

Do I really need to write an introduction to button components? We all know them. Buttons are one of the most commonly used components in our user interfaces, and are also some of the messiest components, with crappy interfaces and complex implementations for something as simple as a freaking button, and they only get worse as your codebase ages.

In this post, I’ll briefly explain why button components are a classic problem in software engineering, how composition can solve this problem, and how I implement complex buttons with simple code these days.

Read more
· 1 minute read

URL Fragments and pushState() are weeeiiird

Yesterday I learned two weird things that happen when you use pushState() to navigate to a page with a URL fragment:

  1. The CSS :target selector doesn’t work. You can use :target to style an element that is the current URL fragment when doing a full document load, but not with pushState! This is also documented on MDN:

    The target element is set at document load and history.back(), history.forward(), and history.go() method calls. But it is not changed when history.pushState() and history.replaceState() methods are called.

    But that’s weird! Why not? I would argue that it makes :target a little bit unusable in modern web applications. Even though it’s such a useful feature!

  2. The hashchange event doesn’t fire. Even though the hash changes, the event doesn’t fire. This is also documented on MDN, but oddly enough it’s documented in the pushState docs, and not in the hashchange docs.

    Note that pushState() never causes a hashchange event to be fired, even if the new URL differs from the old URL only in its hash.

    That’s weird! And unexpected. This note should be included in the hashchange docs. Might be a good opportunity to open a small pull request.

Update: I did indeed open a small pull request and the hashchange docs now also explain this behavior.

· 4 minute read

User-defined color theme in the browser without the initial flash

When adding dark and light mode to your site, a common approach is to store the theme in localStorage and reading it on the next visit. But our JavaScript usually runs after the page loads, so reading it in JavaScript can cause a flash of the wrong theme—like flashbanging dark mode users with light mode. We can fix this with a small script in the <head>. But wait—isn’t that a blocking script? Aren’t those bad? Let’s take a quick look at why that’s not always true.

Read more
· 3 minute read

The Curse of the astray Service Worker

When I published my new site last week, I continued to still see my old site. Initially I thought it was just DNS, but after a short while it dawned on me, that my old site used a Service Worker which cached everything and made it offline available. When you visited my old site, it automatically installed the Service Worker, and continued to serve it from cache. And now, if you visited my new site, it still served my old site. Great.

Read more