CSS that doesn't fail: common styling mistakes on web pages and how to avoid them

CSS seems simple until something doesn’t work as you expect. You spend hours staring at the browser inspector, change one property, then another, and the problem persists. This article collects the most frequent errors I’ve encountered building this blog, with direct solutions.

The background that disappears when scrolling

#

The problem: The page looks good in the visible area, but when you scroll down a white or unexpected background appears.

Why it happens: The background color is defined in an inner container (like main or article), not in html or body. When the content is shorter than the window, the rest of the page is left without color.

The solution:

/* MAL: solo el body tiene color */
body {
  background-color: #0f172a;
}

/* BIEN: también html, para cubrir toda la página */
html,
body {
  background-color: #0f172a;
  min-height: 100%;
}

This guarantees that the background covers from the first pixel to the last, regardless of how much content there is.

Dark mode that only applies partially

#

The problem: You activate dark mode and some elements change, but others remain with a light background.

Why it happens: Dark mode in frameworks like Tailwind or Blowfish works by adding the .dark class to the html element. If your custom CSS only targets body, it may lose color in certain cases.

/* Puede fallar en algunos navegadores */
html.dark body {
  background-color: #0f172a;
}

/* Más robusto: apuntar también a html */
html.dark,
html.dark body {
  background-color: #0f172a;
}

Practical rule: when working with class-based dark mode, always apply the background color to both html and body.

background-image without background-color

#

The problem: You have an SVG pattern or background image, but in areas where the image doesn’t load or takes time, a white background appears.

The solution: Always define a fallback background-color along with background-image:

body {
  background-color: #0f172a;           /* fallback si la imagen no carga */
  background-image: url("/patron.svg");
  background-size: 120px 120px;
  background-repeat: repeat;
}

The color acts as a safety net. The user never sees a white flash while the SVG loads.

background-attachment: fixed and the mobile problem

#

The problem: The parallax effect with background-attachment: fixed looks good on desktop but on mobile the background appears static, cropped, or shifted strangely.

Why it happens: Most mobile browsers ignore fixed on elements that aren’t html/body, and some implement it with known bugs in iOS Safari.

The solution: Disable it on mobile:

body {
  background-attachment: fixed;
}

@media (max-width: 768px) {
  body {
    background-attachment: scroll; /* o simplemente eliminar el patrón */
    background-image: none;
  }
}

z-index and content disappearing behind the background

#

The problem: You add a decorative background and suddenly text or interactive elements disappear or become inaccessible.

Why it happens: The background has a higher z-index than the content, or the content doesn’t have position defined (necessary for z-index to work).

/* El fondo queda detrás */
.fondo-decorativo {
  position: fixed;
  z-index: 0;
}

/* El contenido queda encima */
main,
article,
.contenido {
  position: relative;
  z-index: 1;
}

Specificity: when your CSS doesn’t override the framework’s

#

The problem: You write a CSS rule but it has no effect. The inspector shows it’s being overridden by the framework (Tailwind, Bootstrap, etc.).

Why it happens: CSS specificity determines which rule wins. A class selector (.dark body) has less weight than a compound selector from the framework.

Solutions in order of preference:

/* 1. Aumentar especificidad añadiendo el padre */
html.dark body { ... }

/* 2. Usar :is() para agrupar sin perder especificidad */
:is(html.dark) body { ... }

/* 3. !important — solo como último recurso */
body { background-color: #0f172a !important; }

Avoid !important whenever you can — it creates a specificity debt that accumulates and makes CSS impossible to maintain.

CSS Variables: order matters

#

The problem: You define CSS variables (custom properties) but in some contexts they don’t work.

Why it occurs: CSS variables (custom properties) are only accessible in the element where they are defined and its descendants. If you define them in body, they will not be available in html.

/* BIEN: definir en :root para disponibilidad global */
:root {
  --color-fondo: #0f172a;
  --color-texto: #f1f5f9;
}

/* Luego úsalas en cualquier elemento */
body {
  background-color: var(--color-fondo);
  color: var(--color-texto);
}

Quick debugging with the inspector

#

When something doesn’t work:

1. Open DevTools (F12) and select the problematic element
2. In the Styles tab, look for crossed-out properties — they are being overridden
3. Filter by :hov to see styles for states (:hover, :focus)
4. Toggle dark mode from DevTools: Rendering panel → Emulate CSS media feature prefers-color-scheme
5. Use the Computed tab to see the final value that actually applies

Most of these errors have the same root cause: assuming that the style propagates upward in the DOM when it actually only goes down. html and body are the starting point — make sure they look exactly like you want before worrying about the rest.

Recommended equipment

#

• Raspberry Pi 3 B+ — Lightweight, low-power server to start your homelab
• Raspberry Pi 4 (4GB) — The perfect foundation for homelab, Docker and monitoring

Affiliate links. No extra cost to you.