DEV Community: Khaled Sabry

CSS Works in Chrome but Not Safari or Firefox? A Real Example and Fix

Khaled Sabry — Mon, 12 Oct 2026 12:01:44 +0000

We've all been there.

You write some CSS, open your page in Chrome, and everything works exactly as expected.

Then you open Safari or Firefox.

Suddenly, something that should be simple behaves completely differently.

I recently came across an interesting Reddit discussion in r/css where a developer encountered exactly this problem.

The interesting part? It wasn't a complicated layout, JavaScript framework, or browser animation.

It was a small CSS example involving @property and container style queries.

I decided to reproduce the problem, compare its rendering across browsers using Preveo, and then test a possible fix.

Here's what happened.

1. The Original Problem: Same CSS, Different Results

The original Reddit post, titled "Possible CSS Bug", was published on August 12, 2026.

The developer created a minimal example using a registered CSS custom property.

The CSS looked like this:

@property --im-a-color {
    syntax: "<color>";
    inherits: false;
    initial-value: red;
}

.red {
    --im-a-color: red;
}

.blue {
    --im-a-color: blue;
}

@container style(--im-a-color) {
    h1 {
        color: green;
    }
}

And the HTML contained three headings:

<div>
    <h1>I should be black</h1>
</div>
<div class="red">
    <h1>I should also be black</h1>
</div>
<div class="blue">
    <h1>I should be green</h1>
</div>

The expected result was straightforward:

Element	Expected color
First heading (default)	Black
Second heading (`.red`)	Black
Third heading (`.blue`)	Green

The reason is the registered custom property's initial value.

Since --im-a-color starts at red, a boolean style query should evaluate to true only when its computed value differs from that initial value.

Chrome rendered the example as expected, but the original developer reported different behavior in Safari and Firefox.

This raised an interesting question:

Was the CSS wrong, or were browsers interpreting the same CSS differently?

Open the original JSFiddle

2. Why This CSS Is Interesting

The key line is:

@container style(--im-a-color)

Unlike a traditional media query, a container style query can apply CSS based on a custom property's computed value on an ancestor.

When using the boolean form with a registered custom property, the condition is supposed to match when that value differs from its registered initial value.

In our case:

Initial value: red
.red value: red
.blue value: blue

Therefore, only the blue example should receive the green heading style.

This isn't simply about whether a browser supports container queries. It's about whether its implementation produces the expected result for this particular condition.

According to MDN's documentation on container style queries, registered custom properties have specific matching behavior based on their initial values.

That makes the original Reddit example particularly useful: it's small enough to isolate one browser behavior without introducing unrelated layout complexity.

3. I Ran the Example Through Cross-Browser Testing

Instead of trying to diagnose the problem by switching browsers manually, I used Preveo, a tool I've been building to evaluate websites and identify UI problems.

One of its capabilities is comparing how the same webpage renders in different browser engines:

Chromium
Safari (WebKit)
Firefox (Gecko)

The idea is simple: load the same page in multiple browsers, capture the rendered results, and compare them visually.

For this test, I used the original JSFiddle and ran a cross-browser evaluation.

Before Fix — Preveo Report

View the original cross-browser evaluation

The important thing wasn't just identifying which browser looked different. It was having a reproducible example and a visual reference that could be checked again after making a code change.

This is especially useful with CSS because two browsers can accept the same declarations while producing different visual results.

And when that happens in a real application, the consequences can be much more noticeable than a heading having the wrong color.

Imagine the same kind of difference affecting a navigation bar, pricing card, product button, or an entire theme.

4. The Fix: Be Explicit About the Value

For this particular example, I changed the container query from a boolean condition to an explicit value comparison.

Before:

@container style(--im-a-color) {
    h1 {
        color: green;
    }
}

After:

@container style(--im-a-color: blue) {
    h1 {
        color: green;
    }
}

It's a small change, but an important one.

The original condition asks:

Is the computed value different from the property's initial value?

The updated condition asks:

Is the computed value blue?

That is a more precise statement of what this particular example needs.

I also added an explicit default heading color:

h1 {
    color: black;
}

This ensures the intended fallback appearance is clear rather than depending on inherited or browser-default text colors.

The updated example also includes basic HTML document metadata and a small JavaScript diagnostic that logs the computed custom property and heading color.

Open the updated JSFiddle

An important technical distinction

The explicit query is a practical workaround for this use case, not a universal replacement for boolean style queries.

For example, if the custom property were changed to green, the original boolean query should still match because green differs from red.

The explicit blue query would not match.

So this fix makes sense when the intended design is specifically tied to the blue value. It does not establish that the original CSS was invalid, nor does it resolve the underlying browser implementation discrepancy.

5. Running the Test Again

After modifying the CSS, I evaluated the updated example through the same cross-browser workflow.

After Fix — Preveo Report

View the updated cross-browser evaluation

Here are the two versions if you want to compare them yourself:

	Original	Updated
CSS example	Before JSFiddle	After JSFiddle
Cross-browser evaluation	Before report	After report

The useful part of this workflow is being able to evaluate both versions rather than relying on one successful Chrome test.

A proper regression check should verify that the updated result matches the intended appearance in every browser tested, not just that it looks better in one.

For a small example like this, that means confirming the heading colors.

For a production website, it could mean comparing entire pages, typography, component styles, and layout behavior.

6. What I Learned from This Example

There are three things I think developers should take away from this.

1. Browser support doesn't always mean identical behavior

Seeing a feature listed as supported doesn't guarantee that every browser version handles every edge case identically.

That doesn't automatically make one browser right and another wrong. The specification, implementation details, and exact browser versions all matter.

2. A small reproducible example is incredibly valuable

The original developer reduced the problem to three headings and a few CSS declarations.

That made it much easier to understand what was being tested.

If you encounter an unexpected rendering difference, isolating the smallest possible example is often more productive than debugging an entire application.

3. Test the fix across browsers, not just where the problem appeared

It's possible to fix something in Safari and accidentally change the appearance in Chrome.

That's why I prefer comparing the original and updated versions across multiple browser engines.

The goal isn't simply to remove one visual difference.

The goal is to make sure the intended experience works consistently for everyone.

7. Why I Think Cross-Browser Testing Still Matters

Modern frontend development has become dramatically faster.

We have AI coding assistants, component libraries, CSS frameworks, and tools that can generate entire interfaces from a prompt.

But there's a problem.

Generating the interface is not the same as validating the interface.

Your application might work perfectly in the browser you use for development while looking different for someone opening it in Safari or Firefox.

And often, you won't notice until a customer reports it.

This is one of the problems I'm trying to address with Preveo.

Instead of manually opening every page in multiple browsers and trying to spot differences, I wanted a way to evaluate browser rendering side by side, identify meaningful inconsistencies, and produce actionable suggestions for fixing them.

The example from Reddit is small, but it illustrates the larger issue perfectly.

Even a few lines of valid-looking CSS can deserve cross-browser testing.

Final Thoughts

What started as a Reddit post about a possible CSS bug became an interesting example of why cross-browser validation matters.

The practical fix for this case was small:

/* Before */
@container style(--im-a-color) { /* ... */ }

/* After */
@container style(--im-a-color: blue) { /* ... */ }

But the bigger lesson is that CSS working in one browser isn't proof that it works everywhere.

If you're building websites—whether manually, with React, using Lovable, or with an AI coding assistant—it's worth checking how the actual result looks across browsers before shipping.

You can explore the example yourself:

And if you want to evaluate your own website across Chromium, Safari, and Firefox, you can try Preveo.io.

Have you ever had CSS work perfectly in Chrome but behave differently in Safari or Firefox? I'd be interested to hear which browser differences have caused you the most trouble.

I Improved My Website’s SEO Score from 77 to 96 Using One AI Prompt

Khaled Sabry — Sun, 11 Oct 2026 07:31:35 +0000

How I used an AI-powered SEO evaluation, generated a fix prompt, and let Codex handle the improvements.

I've been building my website for a while, and like many developers using AI tools, I assumed that if the page looked good and worked properly, the SEO was probably fine too.

Turns out, I was missing quite a few things.

I decided to run an SEO evaluation on my website using Preveo.io to see what could be improved.

My initial score was 77/100.

Not terrible, but definitely room for improvement.

What surprised me wasn't the score itself. It was how many relatively small issues I had overlooked, and how straightforward some of them were to fix.

Instead of spending hours manually going through the findings, I tried something different.

I generated a single AI fix prompt, gave it to Codex, applied the changes, and evaluated the page again.

The result? 77 → 96. A 19-point improvement.

Here's what I did and what I learned.

Step 1: Evaluate the Website Before Changing Anything

One mistake I've made when improving websites is jumping straight into fixes without fully understanding what's wrong.

This time, I wanted to start with an evaluation.

I used an SEO evaluation macro called Improve Page SEO in Preveo.

The macro analyzes the actual webpage, looking at elements such as:

Page title and meta description
H1 and heading hierarchy
Content structure and keyword clarity
Image alt attributes
Internal and external links
Canonical URLs and indexing signals
Structured data

The useful part is that the evaluation isn't just based on how the website looks in a screenshot. It examines the on-page elements that search engines use to understand a website.

After running it, I received a report showing which elements were already in good shape and which could benefit from changes.

My starting score: 77/100.

View my original SEO evaluation

Step 2: Understand What Was Actually Hurting the Score

Going through the findings reminded me that good SEO isn't necessarily about adding more keywords or writing longer content.

Sometimes, it's about making the website easier to understand.

Here are five lessons I took away from the process.

1. Your Headline Should Explain What You Do

A catchy headline is great for marketing, but visitors and search engines also need to understand what your product actually offers.

It communicates an idea, but without supporting context, it doesn't fully explain the product.

A descriptive subheading can help connect that message to what the product does and who it's for.

The lesson: Keep your creative messaging, but make sure the surrounding content provides clarity.

2. Meta Descriptions Deserve Attention

It's easy to spend hours designing a landing page and almost no time reviewing how it might appear in search results.

Your page title and meta description are an opportunity to explain why someone should click.

A good description should:

Communicate what the page offers.
Use natural language.
Match the actual content.
Avoid unnecessary keyword stuffing.

3. Image Descriptions Matter

Not every image needs a long description, but meaningful images should have relevant alt text.

This helps accessibility and gives search engines additional context.

For purely decorative images, an empty alt attribute can be more appropriate.

4. Your Content Needs a Clear Structure

A website can look visually organized while having a confusing heading hierarchy underneath.

Using headings consistently helps visitors navigate content and makes the page structure easier for search engines to interpret.

5. Small Technical Details Are Easy to Miss

Canonical URLs, indexing directives, structured data, and descriptive links aren't always visible in the UI.

That's exactly why reviewing the actual webpage matters.

A visual inspection alone won't tell you whether everything is configured correctly.

Step 3: Generate One Fix Prompt Instead of Fixing Everything Manually

This was my favorite part of the experiment.

Once I had the SEO evaluation, I used its findings to create an AI fix prompt.

The idea was simple:

Rather than manually translate every recommendation into a code change, give a coding agent the relevant evidence and ask it to handle the confirmed issues.

I copied the prompt into Codex, which had access to my website's codebase.

The prompt instructed the agent to:

Review the SEO evaluation findings.
Verify each issue against the actual implementation.
Identify which recommendations were genuinely necessary.
Make the appropriate code changes.
Avoid unnecessary changes just to improve the score.

That verification matters.

AI-generated reports aren't automatically correct, and I didn't want changes made simply because a tool suggested them.

The coding agent could inspect the existing implementation before editing anything.

After the changes, I pushed the updated website and ran the same SEO evaluation again.

Step 4: Run the Evaluation Again

This was the moment I was most interested in.

Did the changes actually improve anything?

The second evaluation came back with a score of 96/100.

Before vs. After

Metric	Before	After
SEO evaluation score	77/100	96/100
Score improvement	—	+19 points
Evaluation method	Preveo SEO Macro	Same macro
Code improvements	Not yet applied	Applied using Codex

View my updated SEO evaluation

One important distinction: This was an improvement in the evaluation score, not proof of a 19% increase in Google rankings or organic traffic.

Search performance takes time to measure, and better on-page SEO doesn't guarantee better rankings.

But it did give me a measurable way to see whether the changes addressed the issues identified in the first review.

And that's valuable on its own.

The Workflow I Want to Keep Using

The whole experience made me think differently about improving websites with AI.

We have plenty of tools that help us build websites quickly.

Lovable, Bolt, Replit, Cursor, Claude Code, and Codex are all examples of how much easier building has become.

But once the website is built, there's another question:

How do you know what still needs improvement?

That's where I think an evaluation-first workflow makes sense.

My Process

Evaluate → Understand → Generate Fix Prompt → Apply Fixes → Re-evaluate

I used Preveo for the evaluation and Codex to make the code changes.

The distinction is useful:

Preveo: Identifies what needs attention and generates actionable findings.
Codex: Reviews the findings, verifies the issues, and implements the code changes.
Preveo again: Re-evaluates the website to measure the improvement.

It also means I don't have to rely entirely on how polished the page looks or whether the coding agent says it's finished.

I can run another evaluation after making changes.

A Few Things I'd Do Differently Next Time

I learned that a higher score shouldn't be the only goal.

Some SEO recommendations may not be appropriate for every page, and adding unnecessary keywords, sections, or structured data just to satisfy a checklist can make the website worse.

Next time, I'd also track:

Google Search Console impressions
Organic search clicks
Indexing status
Search queries and ranking changes
Actual organic traffic over time

That would help distinguish improvements in on-page SEO implementation from actual changes in search performance.

I'd also prioritize recommendations that genuinely help visitors understand and use the website, rather than treating every possible optimization as mandatory.

Final Thoughts

Going from 77 to 96 was satisfying, but the bigger takeaway was the workflow.

I didn't need to manually inspect every metadata field or write individual instructions for each issue.

I could evaluate the page, identify meaningful improvements, let a coding agent implement the verified fixes, and run the evaluation again.

If you're building a website using Lovable, Bolt, Replit, Codex, or any other AI-assisted development tool, I'd recommend trying an evaluation before asking the AI to make random improvements.

You might find problems you didn't even know to look for.

And sometimes, one well-structured fix prompt is enough to make a noticeable difference.

DEV Community: Khaled Sabry

CSS Works in Chrome but Not Safari or Firefox? A Real Example and Fix

1. The Original Problem: Same CSS, Different Results

2. Why This CSS Is Interesting

3. I Ran the Example Through Cross-Browser Testing

4. The Fix: Be Explicit About the Value

An important technical distinction

5. Running the Test Again

6. What I Learned from This Example

1. Browser support doesn't always mean identical behavior

2. A small reproducible example is incredibly valuable

3. Test the fix across browsers, not just where the problem appeared

7. Why I Think Cross-Browser Testing Still Matters

Final Thoughts

Other Articles

I Improved My Website’s SEO Score from 77 to 96 Using One AI Prompt

How I used an AI-powered SEO evaluation, generated a fix prompt, and let Codex handle the improvements.

Step 1: Evaluate the Website Before Changing Anything

Step 2: Understand What Was Actually Hurting the Score

1. Your Headline Should Explain What You Do

2. Meta Descriptions Deserve Attention

3. Image Descriptions Matter

4. Your Content Needs a Clear Structure

5. Small Technical Details Are Easy to Miss

Step 3: Generate One Fix Prompt Instead of Fixing Everything Manually

Step 4: Run the Evaluation Again

Before vs. After

The Workflow I Want to Keep Using

My Process

A Few Things I'd Do Differently Next Time

Final Thoughts

Resources From My Experiment