LinuxTampa, LLC Blog

When Gemini's Answer Column Is Narrower Than Its Own Table

2026-09-23T00:00:00Z

The Setup

I was asking Google Gemini a handful of questions in the web UI. The topic doesn't matter here. One of the answers came back as a table, which is exactly the right format for the content: several rows, several columns, each cell a short phrase.

The table was slightly too wide for the reply column. Nothing was broken, exactly: a horizontal scrollbar appeared at the bottom of the table, and scrolling right revealed the hidden columns. But I wanted a screenshot of the entire table, and you can't screenshot something you have to scroll to see. My window was wide, with plenty of unused space on both sides of the reply. Gemini just wouldn't let the table use it.

The table, highlighted, inside Gemini's default reply column. It's scrolled sideways: the first column ("Target Type") is cut off on the left, and the text fades out on the right. You never see all four columns at once.

What's Going On

Chat UIs put the conversation in a centered column with a max-width, usually somewhere between 700 and 800px. It's a sound default for prose, since long lines of text are hard to read. It's also why a chat that renders paragraphs beautifully can struggle the moment the model emits something inherently wide: a table, a long code line, a URL.

A table is different from a paragraph. Text wraps to fit its container. A table's columns have a minimum content width, so once there are enough columns the table is wider than its container, and the browser has to decide what to do with the overflow. Roughly, there are three outcomes:

Container's `overflow`	What you see
`visible` (default)	The table spills out past the column. Ugly, but everything is readable
`auto` / `scroll`	A horizontal scrollbar appears; you can scroll to the hidden columns
`hidden`	The overflow is clipped. The columns are still in the DOM, but you can't reach them

Gemini was in the middle row: the scrollbar tells me the table sits inside a container that scrolls sideways. That's a perfectly reasonable design. It just isn't what I needed at that moment.

There's one more detail, and it's the one that aggravated me most: the fade. Look at the left and right edges of the table in the first screenshot. The text doesn't stop at the edge of the column; it fades out, so the last few characters of every cell on either side are washed out and hard to read. I assume it's meant as a hint that there's more content off-screen, and as a hint it's fine. But it means the part of the table you can see isn't fully legible either, and a screenshot of a table that fades at both ends is useless for what I wanted. As far as I can tell, you can't switch it off.

What I can't tell you is which element carries the narrow limit. I opened DevTools and went looking for the property, and I never found it. The page is a deep pile of nested elements with generated class names, and a max-width can sit on any ancestor, or come from a grid or flex layout rather than a declaration I could spot.

Workarounds

Roughly in order of effort:

Zoom out. Ctrl + - shrinks everything. It only helps if the column's width isn't fixed in CSS pixels, because a max-width in pixels scales down along with the table. Cheap to try.
Fix it in DevTools. Right-click the table, choose Inspect, walk up the tree until you find the ancestor with the max-width, and untick it. Instant, but it disappears on reload, and it only works if you can find the right ancestor. I couldn't.
Export the table. Gemini has an export button on its tables. That's the right tool if you want the data, but it wasn't what I needed: I wanted a picture of the table as it was rendered in the conversation.
Make the fix permanent with a user style. A browser extension that injects your own CSS into a site. This is what I ended up doing.

What Actually Worked: Asking Gemini to Fix Gemini

Having failed in DevTools, I did the slightly absurd thing and asked Gemini how to permanently widen its own response column. It suggested installing a Firefox extension called Custom CSS and applying these rules to the Gemini site:

main,
[role="main"],
article,
div[class*="content"],
div[class*="markdown"] {
  max-width: 92vw !important;
  width: 100% !important;
}

/* Neutralize narrow grid or flex layout restrictions */
main *,
[role="main"] * {
  max-width: 100% !important;
}

It worked on the first try: the reply column now takes up most of the window, the table fits, and I got my screenshot.

The same table after applying the CSS: all four columns visible at once.

It was a helpful enough answer that I gave it a thumbs up. The browser doesn't matter to the CSS itself, since Chrome and others would render the page the same way, but the extension I used is a Firefox add-on, so on another browser you'd need its equivalent.

Why it works, and why I'm a little uneasy about it

This is a shotgun, not a scalpel. It's what you write when you can't find the one rule responsible:

The first block covers every plausible container. main, [role="main"] and article are structural elements. div[class*="content"] and div[class*="markdown"] are attribute selectors that match any div whose class name merely contains those words. Gemini's real class names are generated and opaque, so this is guessing that some of them contain "content" or "markdown". It happens to hit.
The second block, main * { max-width: 100% !important }, removes the cap from every descendant of main. That's the part that defeats layout constraints I couldn't locate: whichever nested element had the narrow limit, it now can't exceed its parent, and the parent is now 92% of the viewport.
!important on everything is how it wins against the site's own rules without knowing their specificity. It's also why it's brittle to debug.

The tradeoffs are real. It will break if Google restructures the page or renames the classes those substring matches depend on. The universal main * rule may affect things that were supposed to have their own widths, such as buttons, popovers and the input box, so it's worth a look at the whole page and not just the table. A table wider than 92% of the window would still get its scrollbar. And reading prose across a 92vw column is harder on the eyes, which is the reason the original column was narrow in the first place.

I'll take that trade, because the alternative was stitching several screenshots together. But if you go this route, a better long-term version is the one I couldn't write: find the real element and target it directly.

Would This Affect Code Blocks and CSV Too?

I only saw this with a rendered Markdown table, and that's all I tested. My guess is that any wide content inside the same column would run into the same limit, including a code block or CSV output, but I haven't verified that.

Building a Dark Mode Toggle That Plays Nice With Dark Reader

2026-08-12T00: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.

Update: Now an npm Package

I liked this pattern enough that I pulled it out of this site and turned it into a proper package: dark-reader-aware-theme-toggle-button (npm).

It's the same idea as above, hardened a bit further — it checks all four DOM signals Dark Reader can leave behind (dynamic and filter/static modes, not just data-darkreader-scheme), ships TypeScript types, and has zero runtime dependencies. Both this site and bailey-jones.com run on it now.

npm install dark-reader-aware-theme-toggle-button

import { mountThemeToggleButton } from 'dark-reader-aware-theme-toggle-button';
import 'dark-reader-aware-theme-toggle-button/styles/toggle-button.css';

mountThemeToggleButton({
  button: '#theme-toggle',
  label: '#theme-toggle-text',
});

Everything else on this page — the reasoning, the MutationObserver, the visibility: hidden trick — still holds. The package just saves you from copy-pasting it into every project.

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.