LinuxTampa, LLC Blog

Building a Dark Mode Toggle That Plays Nice With Dark Reader

2026-03-18T00:00:00Z

Why I Care About This

In 2022, I had life-changing eye surgery — lens replacement. Before the surgery, I could not read bright white screens without significant pain and discomfort. Dark Reader became a non-negotiable part of my browser setup. Every site I visited got inverted whether the developers intended it or not. But sometimes a web offers a dark mode toggle but it actually conflict with DarkReader's efforts.

I'm not alone. Millions of people depend on Dark Reader and similar extensions for accessibility reasons — photosensitivity, migraines, recovering from eye surgery, or simply preferring low-luminance environments. Many of them have no control over their viewing conditions. Think about screen sharing: when someone else is presenting, you're stuck with whatever theme their machine is running.

With the new artificial lens in each eye now, I can handle bright screens again — though I still prefer dark. But the issue is still important to me, because #empathy is an important value.

But building this site gave me a fresh appreciation for the problem from the other side: what happens when your site's dark mode toggle and Dark Reader are both active at the same time?

The short answer: they fight, and it looks terrible.

The Problem

When you build a dark mode toggle into your site, you're typically doing something like this:

// Set dark mode
document.documentElement.setAttribute('data-theme', 'dark');

// Set light mode
document.documentElement.removeAttribute('data-theme');

And your CSS looks like:

:root {
  --bg-main: #fdf8f2;
  --text-primary: #2c1a0e;
}

[data-theme="dark"] {
  --bg-main: #0f150f;
  --text-primary: #00ff9f;
}

This works beautifully on its own. But Dark Reader works by injecting its own stylesheet into the page — it analyzes your colors, inverts them, and applies its own data-darkreader-scheme attribute to <html>. If your toggle is also active, both stylesheets are fighting over the same elements. The result is an ugly, inconsistent mess: some things are double-inverted back to light, others are a muddy combination of both themes.

The polite solution is to detect that Dark Reader is present and step aside.

Detecting Dark Reader

Dark Reader signals its presence by adding a data-darkreader-scheme attribute to the <html> element. You can check for it directly:

const isDarkReaderActive = () =>
  document.documentElement.hasAttribute('data-darkreader-scheme');

The catch: Dark Reader injects asynchronously after the page loads. If you check at DOMContentLoaded, you'll often check before DR has done anything. A simple setTimeout workaround is fragile — network speed, extension load order, and browser quirks all affect timing.

The right event to catch these changes is called a MutationObserver. It watches the DOM for changes and fires a callback the instant Dark Reader adds or removes its attribute — no polling, no race conditions, NO EXCUSES!

The Solution

Here's the complete dark mode toggle script with Dark Reader awareness built in:

(function() {
  const themeToggle = document.getElementById('theme-toggle');
  const themeToggleText = document.getElementById('theme-toggle-text');
  const html = document.documentElement;

  const setTheme = (theme) => {
    if (theme === 'dark') {
      html.setAttribute('data-theme', 'dark');
      themeToggleText.textContent = 'Light';
      localStorage.setItem('theme', 'dark');
    } else {
      html.removeAttribute('data-theme');
      themeToggleText.textContent = 'Dark';
      localStorage.setItem('theme', 'light');
    }
  };

  // Restore saved preference on load
  setTheme(localStorage.getItem('theme') || 'light');

  themeToggle.addEventListener('click', () => {
    const current = html.getAttribute('data-theme');
    setTheme(current === 'dark' ? 'light' : 'dark');
  });

  // Hide our toggle if Dark Reader is active — it's already doing the job.
  // Use visibility:hidden instead of display:none to preserve layout spacing.
  const checkDarkReader = () => {
    const drActive = html.hasAttribute('data-darkreader-scheme');
    themeToggle.style.visibility = drActive ? 'hidden' : '';
  };

  checkDarkReader();

  new MutationObserver(checkDarkReader).observe(html, {
    attributes: true,
    attributeFilter: ['data-darkreader-scheme']
  });
})();

The key decisions:

attributeFilter: ['data-darkreader-scheme'] — We're only watching for the one attribute we care about. Without this filter, the observer would fire on any attribute change to <html>, including our own data-theme toggles, causing unnecessary callbacks.

visibility: hidden instead of display: none — This is a subtle but important distinction. display: none removes the element from the layout flow entirely. If your toggle button is a flex child in your nav bar, hiding it with display: none collapses that slot and causes the remaining nav items to shift. visibility: hidden makes the element invisible while preserving its space in the layout — the nav stays perfectly centered regardless of whether the button is visible.

/* What we want — button disappears, space remains */
themeToggle.style.visibility = 'hidden';  /* ✓ */

/* What we don't want — button disappears, nav shifts */
themeToggle.style.display = 'none';       /* ✗ */

The HTML

Your toggle button just needs an ID and a text span to update:

<button id="theme-toggle" aria-label="Toggle dark mode">
  <span id="theme-toggle-text">Dark</span>
</button>

When Dark Reader is active, the button is invisible but still in the DOM, still taking up space, and the MutationObserver is still watching. The moment a user disables Dark Reader, the observer fires, the button reappears, and your toggle is fully functional again.

A Note on Accessibility

If you're building for an audience that includes people with photosensitivity or visual impairments, a well-implemented dark mode isn't just a nice-to-have — it's a courtesy. Dark Reader exists because browsers and operating systems were late to the party on system-level dark mode, and many sites still don't respect prefers-color-scheme at all.

The approach above respects the user's choice: if they've installed Dark Reader, they've made a deliberate decision about how they want to see the web. Your toggle doesn't fight them — it just quietly gets out of the way.

If you want to go further, you can also respect the system preference on first load by checking prefers-color-scheme before falling back to your saved localStorage value:

const getInitialTheme = () => {
  const saved = localStorage.getItem('theme');
  if (saved) return saved;
  return window.matchMedia('(prefers-color-scheme: dark)').matches
    ? 'dark'
    : 'light';
};

Small things. Big difference for the people who need them.

Starting Fresh: Why I Launched LinuxTampa

2026-03-10T00:00:00Z

After more than three decades writing software for large organizations, I recently made the leap to independent consulting under the banner of LinuxTampa, LLC.

This wasn't entirely by choice — the W-2 market has been brutal lately, and I'm far from alone in that experience. But the more I've leaned into contract work, the more I've realized it suits me. I get to pick interesting problems, work with a wider range of technology stacks, and spend less time in status meetings.

What LinuxTampa Is

LinuxTampa is my vehicle for helping businesses get real value out of open source technology and cloud infrastructure. The name reflects where I live and what I've built my career on: Linux, in all its forms, from embedded systems to enterprise cloud.

Over the years I've worked across a wide range of domains — telecommunications, financial services, defense, robotics, AI validation. The common thread has been Linux, automation, and a preference for building things that actually last.

What to Expect Here

This blog is where I'll share:

Stories from the field — the real challenges and how we solved them
Technical deep dives — infrastructure, DevOps, cloud architecture
Career observations — what's changing in the industry for experienced engineers

More posts coming soon. If you want to talk about a project, get in touch.

What I'm Looking For in Future Work

2025-05-10T00:00:00Z

What I offer

I have been working with AWS Cloud technologies heavily since 2017, and more recently with GCP (Google Cloud Platform). Before that, I developed many applications going back to the early 1990s. I'm proficient in front-end, back-end, and cloud, and I am at my best in a role where I can contribute on all three fronts.

My canonical resume is on my LinkedIn page, and a skill summary is here, but I'll go over the broad strokes.

What I hate to work with

I don't have a lot of no-go zones, so let's get them out of the way first.

Microsoft Windows
WSL2
Oracle
J2EE

What I love to work with

Linux
I have been a nearly-daily Linux user and developer since Fall '94 Yggdrasil Linux. I have built many custom PCs for Linux Desktop use over the years. I was a RedHat guy until 1999, then switched to Debian, and Ubuntu. I have toyed around with a bunch of other distros, but mostly prefer Ubuntu over CentOS/RHEL/AmazonLinux.

Today, most cloud workloads are Linux-based, from tiny docker containers to entire virtual machines, along with most IaaS/PaaS/SaaS offerings. MacOSX has been Linux-like for many years, and even Microsoft has finally embraced the Linux way (WSL2).
Cloud Computing
Despite having acquired a boatload of Cloud Skills since 2017, I recognize there are still legitimate requirements and demand for on-prem/local servers. Between 1992 and 2016, I worked entirely for companies that operated entirely from data centers and machines in their local headquarters, and in one case, even shipped physical rack-server units with custom apps pre-installed. I still possess those local Linux sysadmin and networking skill sets, and am open to doing this kind of work again.
- AWS
  Since 2017, I have passed 3 AWS certifications over the years (DevOps Pro, Solutions Architect, Developer Associate) (credential SFJZ9X8J1FRQ1HSV)
- GCP
  Since 2022, I began working with Google Cloud Platform, and vastly prefer it for speed, ease of use, more Unix-like tooling, and much lower costs.
- Terraform / OpenTofu
  At first, I learned AWS using CloudFormation for IaC (Infrastructure as Code). Later, I learned the far superior (and portable!) tooling of Terraform, and after that, it became an easy way to become productive with Google Cloud Platform, Azure, and even other services that are not full cloud providers. (Okta, DigitalOcean, GitLab, Kubernetes, all other Hashicorp products among them)
- Digital Ocean — I love these small developer-oriented cloud services. They work with Terraform too!
- Before 2017, all my experience was with on-premises servers. I am comfortable with server hardware and Linux system administration.
Backend Development
- I worked with most of the major programming languages over the years, from C/C++ back in the 1990s, to Java, Python, JavaScript/TypeScript/Node, GoLang, and Java Servlets. Of these, I have come to value GoLang the most.
- I have written many applications that interface to large RDBMS systems, including Postgres, MySQL, Vertica DB, MS SQL Server, and Informix, through ODBC and JDBC connections.
- I am fluent in SQL, query tuning/optimization for a few databases, and database administration.
Frontend Development
I saw my first webpage in 1991 on NetCom, and have been writing web applications ever since. Today, I am fluent in React, and for legacy sites that aren't React, I find that jQuery is still quite relevant. I have generated lots of HTML content with Java Server Pages, PHP, and ColdFusion.

What I look for

Full-time / Remote Work
In addition to the usual advantages of remote work, I get unparalleled peace and quiet working from my rural property.
Variety
I do my best work on small teams that truly embrace DevOps, where each contributor shares responsibility for design, development, testing, deployment, monitoring, and iteration planning. With my very long experience with front-end and back-end development (since 1992), and several years of AWS/GCP work, I look forward to wearing many different hats.

Unfortunately, in some environments, the term devops has become a misused term that describes a team that only works on infrastructure, and doesn't actually develop the application.

I have spent a lot of time in consulting, and that gives me the chance to work in multiple client teams, working practices, and tech stacks. I don't really care what industry I'm working in, because it is the art of building software that interests me above all else. However, I also love building products intended for external consumption, particularly if it is published under an OSI-approved license.
Social Responsibility
Like most developers, I believe in corporate social responsibility, and would be attracted to organizations that promote causes like:
- Universal broadband / access for rural areas & the disadvantaged.
- Better healthcare access & outcomes.
- More access to higher education, voting and civic opportunities.
Conversely, I would not consider working in fossil fuels, polluters, gambling, misinformation, exploitation of others, etc.

Every Site I've Ever Run — A History Since 1998

2023-09-03T00:00:00Z

I have owned and operated a number of websites over the years. Here is a list of them, with a brief description of each.

bailey-jones.com — my personal/music site, started in 2019. It is a static site built with Eleventy.
paperprinciples.com — a website for my late wife's origami crafts. It is a static site, with embedded youtube videos we recorded together.
gotonight.com — a website for a startup I worked for, started in 2012. It was written in Coldfusion, and has been redeveloped in React.
tuckasee.com — This is a site for my father's fine handcrafted bowed psalteries and hammered dulcimers. He retired many years ago, and passed away in March 2026, but I keep this site up as a tribute to him.
sunshinebrass.com — a website for a brass band, started in 2005. It was written in PHP, and is now a static site.
gasparbrass.com — a website for my brass quintet, started in 2005. It was written in PHP, and is now a static site.
adamjones.tech — my son's website, started in 2019. It is a static site, done in React.
timjones.com — my personal website, started in 2015. Now redirects to bailey-jones.com.
tampabaybrass.com — a website for a brass quintet, started in 2000.
carrollwoodbrass.com — a website for a brass ensemble, started in 2012.