DEV Community: Adel Abdelaziz Goucem

Glassmorphism Done Right: 8 CSS Rules for Glass UI People Can Actually Read

Adel Abdelaziz Goucem — Mon, 09 Nov 2026 16:58:04 +0000

Frosted glass looks great in Dribbble shots. In real apps, it often breaks: text you can barely read, no visible edge, a busy background fighting the content, and a phone that slows down because everything is blurred.

The good news: readable glass is not a secret. It comes down to eight simple rules. Let's build a glass card step by step in plain HTML and CSS.

Prefer video? The full walkthrough (English with Arabic subtitles) is above.

The card we're building

<div class="scene">
  <article class="glass">
    <div class="text-area">
      <p class="label">Next appointment</p>
      <p class="time">10:30</p>
      <p>Wednesday, 11 November</p>
      <p>Dr. Lina Haddad, Cardiology</p>
    </div>
  </article>
</div>

1. Background: glass needs something behind it

On a flat background, the blur has nothing to work with and your "glass" looks like a grey box. Add two or three large, soft colour shapes.

.scene {
  background:
    radial-gradient(at 20% 25%, #3D8BEF, transparent 50%),
    radial-gradient(at 80% 75%, #8D6BFF, transparent 50%),
    radial-gradient(at 60% 20%, #2EC7B4, transparent 40%),
    #A9C8E8;
}

Keep the shapes large and calm. Small, busy patterns turn into noise behind the text.

2. Fill: a white layer at about 30%

.glass {
  background: rgba(255, 255, 255, .30);
}

Too low and the card disappears. Too high and it is just a white box. Somewhere between 20% and 40% usually works, but tune it on your real background.

3. Blur: what turns tinted plastic into glass

.glass {
  -webkit-backdrop-filter: blur(20px) saturate(180%);
  backdrop-filter: blur(20px) saturate(180%);
}

backdrop-filter blurs whatever sits behind the element, not the element itself. Around 16 to 24px is the sweet spot: below that the background stays sharp and distracting, above it everything turns to mush.

saturate(180%) keeps the colours behind alive instead of turning grey. And keep the -webkit- prefix: Safari still needs it.

4. Edge: real glass catches light on its rim

.glass {
  border: 1px solid rgba(255, 255, 255, .50);
  box-shadow: inset 0 1px 0 rgba(255, 255, 255, .70);
  background-image: linear-gradient(135deg,
    rgba(255, 255, 255, .22), transparent 40%);
}

A 1px light border draws the rim, an inset highlight on the top edge adds the reflection, and an optional diagonal sheen (keep it under 25%) finishes the effect.

5. Depth: a soft, tinted shadow

.glass {
  box-shadow:
    inset 0 1px 0 rgba(255, 255, 255, .70),
    0 24px 60px rgba(30, 60, 110, .22);
}

Use a shadow tinted with your background colour, not pure black: black shadows look dirty on coloured glass. The bigger the surface, the higher it floats, so give it a larger, softer shadow.

6. Readability: where most glass designs fail

The background moves under the text, so the contrast changes from one spot to another. Test the worst spot, not the best one. Body text needs a contrast ratio of at least 4.5:1 (WCAG AA).

.glass {
  color: #0E2236;      /* not white */
  font-weight: 600;
}
.glass .text-area {
  background: rgba(255, 255, 255, .55);
}

Dark, heavier text plus a slightly stronger fill behind the text area fixes most cases. Never put long paragraphs on glass: keep it to short labels and key numbers.

If your interface is also in Arabic, check it there too. Arabic script often needs a slightly larger size to stay clear:

.glass:lang(ar) { font-size: 1.1em; }

7. Dark mode: don't just invert the colours

Switch the fill to a dark tint around 30% and lower the rim to about 15%. Put every value in CSS variables so one switch changes the whole theme, and respect the user's setting:

:root {
  --glass-fill: rgba(255, 255, 255, .30);
  --glass-rim:  rgba(255, 255, 255, .50);
  --ink: #0E2236;
}
@media (prefers-color-scheme: dark) {
  :root {
    --glass-fill: rgba(12, 24, 40, .30);
    --glass-rim:  rgba(255, 255, 255, .15);
    --ink: #EAF3FA;
  }
}

8. Fallbacks and performance

Some people turn transparency off in their system settings. Give them a solid version:

@media (prefers-reduced-transparency: reduce) {
  .glass {
    background: var(--surface-solid);
    backdrop-filter: none;
  }
}
@supports not (backdrop-filter: blur(1px)) {
  .glass { background: rgba(255, 255, 255, .85); }
}

Blur is also expensive for the phone: every blurred layer costs memory and battery. Keep it to a few surfaces, like the tab bar and sheets, and use solid rows in long lists. And don't animate the blur value itself; move or fade the element instead.

5 mistakes I see all the time

Glass on glass on glass. Stacked blur turns everything muddy. Use one glass surface with solid or almost solid rows inside.
Coloured text on glass. Keep text neutral; use colour for icons and accents.
Thin font weights. Light text disappears on a blurred background. Use 500 or heavier.
Glass buttons. The main action should be solid, so people find it instantly.
The same corner radius everywhere. Outer radius should equal inner radius plus the padding (for example 38 = 14 + 24).

A real example

These rules come from Safaa, a clinic appointment app I designed in English, French and Arabic: glass for the cards and the tab bar, a solid colour for the main button, dark heavy text everywhere, and the same tokens in Arabic and in dark mode.

The full CSS

:root {
  --glass-fill: rgba(255, 255, 255, .30);
  --glass-rim: rgba(255, 255, 255, .50);
  --glass-glow: rgba(255, 255, 255, .70);
  --glass-shadow: rgba(30, 60, 110, .22);
  --text-area: rgba(255, 255, 255, .55);
  --surface-solid: #F4F8FC;
  --ink: #0E2236;
}
@media (prefers-color-scheme: dark) {
  :root {
    --glass-fill: rgba(12, 24, 40, .30);
    --glass-rim: rgba(255, 255, 255, .15);
    --glass-glow: rgba(255, 255, 255, .25);
    --glass-shadow: rgba(0, 0, 0, .45);
    --text-area: rgba(12, 24, 40, .55);
    --surface-solid: #13233A;
    --ink: #EAF3FA;
  }
}
.glass {
  background: var(--glass-fill);
  -webkit-backdrop-filter: blur(20px) saturate(180%);
  backdrop-filter: blur(20px) saturate(180%);
  border: 1px solid var(--glass-rim);
  border-radius: 28px;
  box-shadow:
    inset 0 1px 0 var(--glass-glow),
    0 24px 60px var(--glass-shadow);
  color: var(--ink);
  font-weight: 500;
}
.glass .text-area { background: var(--text-area); }
.glass:lang(ar) { font-size: 1.1em; }
@media (prefers-reduced-transparency: reduce) {
  .glass {
    background: var(--surface-solid);
    backdrop-filter: none;
  }
}
@supports not (backdrop-filter: blur(1px)) {
  .glass { background: var(--surface-solid); }
}

Recap

Colour behind the glass, a fill between 20% and 40%, a blur of 16 to 24px, a 1px light rim, a soft tinted shadow, a contrast of 4.5:1 or more, tokens for dark mode, and fallbacks with only a few blurs.

Which rule do you break most often? Tell me in the comments.

Keep it simple.

My import tool said row 347. The bug was on row 348

Adel Abdelaziz Goucem — Thu, 05 Nov 2026 16:32:45 +0000

My free HR dashboard makes one small, specific promise: when a row in your Excel file is invalid, the import report gives its exact line number, the one Excel shows. While recording a demo, I fed it a file whose row 348 was wrong. The report said row 347.

This post covers why that happened, the few lines that fixed it, and the tests that keep it from coming back. The code comes from HR Dashboard Lite, a free FastAPI and Pandas project (MIT).

A realistic export

HR exports are rarely clean tables. The file I used has a title line, a blank line, then the header, then the data:

Excel row	Content
1	`Fichier du personnel — données fictives` (title)
2	(blank)
3	`Matricule`, `Nom et prénom`, `Date d'embauche`, `Date de départ`… (header)
4	first employee
348	hired 14/06/2021, left 01/03/2019: impossible, so the row must be rejected

The importer detects the header on its own, so the user never has to say where the data starts. That detection is where the line numbers went wrong.

The bug: blank rows vanished before anyone counted

The sheet is read with header=None, then cleaned up. Dropping fully empty rows looked harmless:

# before
raw = raw.dropna(how="all").reset_index(drop=True)
header_row = _find_header_row(raw)
frame = _apply_header(raw, header_row)

Later, the report turned a position in frame into an Excel row number with arithmetic that assumed nothing had been removed:

excel_row = frame.index + header_row + 2

reset_index(drop=True) had just renumbered everything from zero, so the blank row 2 was gone from the count. Every row after it was reported one line too early. With three blank rows, three lines too early. A file without blank rows gave correct numbers, which is why my own tests passed.

The fix: remember where each row came from

I still drop the empty rows, but I keep their original positions before resetting the index, and carry them all the way to the report:

# after
raw = raw.dropna(how="all")          # the index still holds each row's position in the sheet
positions = raw.index.to_numpy()
raw = raw.reset_index(drop=True)
header_row = _find_header_row(raw)
frame = _apply_header(raw, header_row)
excel_rows = [int(positions[i]) + 1 for i in frame.index]

The table object now carries excel_rows, and the validation step reads from it instead of computing a number:

excel_row = pd.Index(excel_rows) if excel_rows is not None else frame.index + header_row + 2

The old formula stays as a fallback for callers that pass a compact table. The rule I took from this: a row number is data, so it should be stored, not recomputed after the data has been reshaped.

The tests that pin it down

The test builds a workbook cell by cell, so the Excel row numbers are explicit, with blank rows before the header and between data:

def test_error_row_is_exact_with_blank_rows_before_and_between_data():
    content = _xlsx({
        1: ["Export du personnel"],
        # row 2 is blank
        3: HEADER,
        4: ["A1", "2020-01-01", None, "F"],
        # rows 5 and 6 are blank
        7: ["A2", "2021-05-01", "2019-01-01", "H"],   # exit before hire: Excel row 7
        8: ["A3", "2022-02-01", None, "F"],
        # row 9 is blank
        10: ["A4", "not a date", None, "F"],           # invalid hire date: Excel row 10
    })
    table = read_table(content, "export.xlsx")
    assert sorted(e["row"] for e in _errors(table)) == [7, 10]

I added the same check for a compact sheet, and for a CSV with a title line and blank lines. The CSV case failed at first for a different reason, covered next.

Two more bugs, found by actually using it

Recording a phone-sized demo exposed two more problems that no unit test had caught.

A CSV with a title line crashed. pd.read_csv infers the number of columns from the first line, so a one-column title above a four-column header raised a ParserError. The fix is to give pandas the width of the widest line:

width = max((len(row) for row in csv.reader(io.StringIO(text), delimiter=delimiter)), default=1)
pd.read_csv(io.StringIO(text), sep=delimiter, header=None, dtype=object,
            skip_blank_lines=False, names=range(width))

The column-mapping screen overflowed on phones. The page switched to a single column with grid-template-columns: 1fr, but 1fr means minmax(auto, 1fr). A wide preview table inside the card set the minimum width, so the whole card grew past the screen and the dropdowns were cut off. One line fixes it:

.import-grid { grid-template-columns: minmax(0, 1fr); }

A small CSS test now checks that line, so a later refactor cannot quietly undo it.

What I would do again

Test with the ugly file first. My early tests used tidy tables, which is exactly the input that hides this bug.
Store identity, don't derive it. If users will see a row number, carry it with the row instead of rebuilding it after the data changed shape.
Use your own tool on a phone and on a messy export. Two of the three bugs here only showed up that way.

The free Lite edition (MIT) is on GitHub: Adel1637/hr-dashboard-lite. It includes the fixes above and 49 automated tests.

What is the worst Excel export you have ever had to import?