Skip to content
93 changes: 56 additions & 37 deletions app/globals.css
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
@import "tailwindcss";

:root {
--bg-base: #0f172a;
--bg-surface: rgba(226, 232, 240, 0.08);
--bg-card: rgba(30, 41, 59, 0.4);
--bg-base: #1a1f35;
--bg-surface: rgba(226, 232, 240, 0.1);
--bg-card: rgba(255, 255, 255, 0.08);
Comment on lines 3 to +6

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 | Confidence: High

The CSS variable --bg-base was changed from #0f172a (very dark navy) to #1a1f35 (a lighter, slightly purplish dark) globally in :root. This variable is intended to be the base background color for the application, and other components or pages not modified in this PR rely on var(--bg-base) to render a dark background. The change will silently alter the background appearance of any such component, potentially breaking visual consistency if those components assumed the original dark tone. This is a breaking change in the global design system that should be coordinated across the entire codebase.

Code Suggestion:

/* Retain old variable for backward compatibility or only change locally */
:root {
    --bg-base: #0f172a;  /* keep original */
}
.revamped-section {
    --bg-base: #1a1f35;  /* override in scoped context */
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P3: The custom properties --bg-surface, --bg-card, and --border-hover are defined/modified here but never referenced anywhere in the codebase — these value changes have no visual effect. Either remove these dead tokens or wire them into actual selectors to prevent a misleading theme contract.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/globals.css, line 6:

<comment>The custom properties `--bg-surface`, `--bg-card`, and `--border-hover` are defined/modified here but never referenced anywhere in the codebase — these value changes have no visual effect. Either remove these dead tokens or wire them into actual selectors to prevent a misleading theme contract.</comment>

<file context>
@@ -1,13 +1,13 @@
-  --bg-card: rgba(30, 41, 59, 0.4);
+  --bg-base: #1a1f35;
+  --bg-surface: rgba(226, 232, 240, 0.1);
+  --bg-card: rgba(255, 255, 255, 0.08);
   --text-primary: #f1f5f9;
   --text-secondary: #cbd5e1;
</file context>

--text-primary: #f1f5f9;
--text-secondary: #cbd5e1;
--border-default: rgba(148, 163, 184, 0.1);
--border-hover: rgba(148, 163, 184, 0.3);
--border-default: rgba(255, 255, 255, 0.2);
--border-hover: rgba(255, 255, 255, 0.3);
Comment on lines +5 to +10

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 Info: Unused CSS custom properties: --bg-card, --bg-surface, --border-hover

The variables --bg-card (app/globals.css:6), --bg-surface (app/globals.css:5), and --border-hover (app/globals.css:10) are defined but never referenced anywhere in the codebase. They were also unused before this PR, but since this PR changed their values, it's worth noting that these value changes have zero effect. These could be cleaned up or they may be intended for future use.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines +5 to +10

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: These newly introduced custom properties are not referenced anywhere in the stylesheet or related UI files, so they are dead configuration and create misleading theme contracts that are easy to drift from real styling logic. Remove them or wire them into actual selectors to keep the design token system consistent. [code quality]

Severity Level: Major ⚠️
- ⚠️ Theme tokens suggest surfaces not actually configurable.
- ⚠️ Future designers may rely on nonfunctional CSS variables.
- ⚠️ Increases drift between documented and real visual system.
Steps of Reproduction ✅
1. Open `app/globals.css` and inspect the `:root` block at lines 3–14 where the design
tokens are declared, including `--bg-surface` (line 5), `--bg-card` (line 6), and
`--border-hover` (line 10).

2. Search the codebase for usages of these tokens; `rg 'var\(--bg-surface'
/workspace/Games` and `rg 'var\(--bg-card' /workspace/Games` return no matches, confirming
that these background tokens are never referenced in any selector or component styles.

3. Search for `border-hover` usages via `rg 'border-hover' /workspace/Games`; the only
match is the definition at `app/globals.css:10`, and there is no `var(--border-hover)`
anywhere, while related styles such as `.language-selector select:hover` at lines 319–323
use `var(--accent)` instead.

4. From this, conclude that `--bg-surface`, `--bg-card`, and `--border-hover` are
currently dead design tokens that do not affect the rendered UI but suggest a theme
contract that is not actually wired into the layout, which can mislead future maintainers
expecting these variables to drive surface and hover styling.

Fix in Cursor | Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** app/globals.css
**Line:** 5:10
**Comment:**
	*Code Quality: These newly introduced custom properties are not referenced anywhere in the stylesheet or related UI files, so they are dead configuration and create misleading theme contracts that are easy to drift from real styling logic. Remove them or wire them into actual selectors to keep the design token system consistent.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
👍 | 👎

--focus-ring: rgba(99, 102, 241, 0.5);
--accent: #6366f1;
--accent-light: #818cf8;
Expand Down Expand Up @@ -56,14 +56,17 @@ body {
z-index: 0;
background: linear-gradient(
135deg,
#0f172a 0%,
#1e293b 25%,
#334155 50%,
#1e40af 75%,
#0f172a 100%
#1a1f35 0%,
#a78bfa 20%,
#60a5fa 40%,
#34d399 60%,
#f472b6 80%,
#1a1f35 100%
);
background-size: 400% 400%;
animation: gradientShift 20s ease infinite;
animation:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Animating CSS filters like hue-rotate and saturate on a full-screen element (such as the background gradient) is extremely resource-intensive. It forces the browser to perform continuous repaints and compositing on every frame, which can lead to high CPU/GPU usage, stuttering animations, and rapid battery drain, especially on mobile devices.

Since the gradientShift animation already shifts the gradient position to create a smooth, dynamic color-shifting effect, the colorCycle animation is largely redundant and can be safely removed to significantly improve rendering performance.

Suggested change
animation:
animation: gradientShift 20s ease infinite;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The new full-screen background now animates filter (hue-rotate/saturate) continuously via colorCycle, which forces expensive per-frame repaint/compositing on the entire viewport and can cause visible jank and high battery/CPU usage on lower-end devices. Prefer animating gradient stops/positions only, or move color shifting to a smaller overlay layer instead of a viewport-wide filter animation. [performance]

Severity Level: Critical 🚨
- ⚠️ Home page always runs full-viewport filter animation.
- ⚠️ Lower-end devices may experience reduced frame rates.
- ⚠️ Increased CPU/GPU usage while user keeps tab open.
Steps of Reproduction ✅
1. Open `app/page.tsx` and note that the `Home` component renders a full-viewport
background via `<div className="animated-gradient" aria-hidden="true" />` at lines 16–18.

2. Open `app/globals.css` and see the `.animated-gradient` rule at lines 53–68, which
fixes the element to cover the entire viewport (`position: fixed; inset: 0;`) and applies
`animation: gradientShift 20s ease infinite, colorCycle 45s ease-in-out infinite;` at line
67.

3. In the same file, inspect the `@keyframes colorCycle` block at lines 82–97, which
animates the `filter` property (`hue-rotate` and `saturate`) on the animated element
itself for the full duration of the app session.

4. Run the app, load the home page, and observe in browser devtools (Performance or
Rendering/FPS overlay) that the full-screen `.animated-gradient` element is continuously
animating a GPU/compositor-affecting `filter` across the entire viewport, which on
lower-end devices will increase CPU/GPU usage and can lower frame rate during the entire
time the page is open.

Fix in Cursor | Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** app/globals.css
**Line:** 67:67
**Comment:**
	*Performance: The new full-screen background now animates `filter` (`hue-rotate`/`saturate`) continuously via `colorCycle`, which forces expensive per-frame repaint/compositing on the entire viewport and can cause visible jank and high battery/CPU usage on lower-end devices. Prefer animating gradient stops/positions only, or move color shifting to a smaller overlay layer instead of a viewport-wide filter animation.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
👍 | 👎

gradientShift 20s ease infinite,
colorCycle 45s ease-in-out infinite;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: These infinite animations (gradientShift + colorCycle) run unconditionally on a full-viewport element without a @media (prefers-reduced-motion: reduce) guard. Users who have requested reduced motion at the OS level will still see continuous full-screen color shifting, which can trigger vestibular disorders or discomfort. Add a reduced-motion media query to pause or disable both animations.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/globals.css, line 69:

<comment>These infinite animations (`gradientShift` + `colorCycle`) run unconditionally on a full-viewport element without a `@media (prefers-reduced-motion: reduce)` guard. Users who have requested reduced motion at the OS level will still see continuous full-screen color shifting, which can trigger vestibular disorders or discomfort. Add a reduced-motion media query to pause or disable both animations.</comment>

<file context>
@@ -64,7 +64,9 @@ body {
-  animation: gradientShift 20s ease infinite, colorCycle 45s ease-in-out infinite;
+  animation:
+    gradientShift 20s ease infinite,
+    colorCycle 45s ease-in-out infinite;
 }
 
</file context>

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: colorCycle animates filter: hue-rotate()/saturate() on a viewport-sized fixed element, which forces a full repaint every frame (filter is not compositor-friendly). This runs indefinitely for the lifetime of the page and can cause jank and battery drain on lower-end/mobile devices. Consider removing colorCycle since gradientShift already provides dynamic color movement via background-position, or move the hue-rotate effect to a smaller overlay layer.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/globals.css, line 69:

<comment>`colorCycle` animates `filter: hue-rotate()/saturate()` on a viewport-sized fixed element, which forces a full repaint every frame (filter is not compositor-friendly). This runs indefinitely for the lifetime of the page and can cause jank and battery drain on lower-end/mobile devices. Consider removing `colorCycle` since `gradientShift` already provides dynamic color movement via background-position, or move the hue-rotate effect to a smaller overlay layer.</comment>

<file context>
@@ -64,7 +64,9 @@ body {
-  animation: gradientShift 20s ease infinite, colorCycle 45s ease-in-out infinite;
+  animation:
+    gradientShift 20s ease infinite,
+    colorCycle 45s ease-in-out infinite;
 }
 
</file context>
Suggested change
colorCycle 45s ease-in-out infinite;
gradientShift 20s ease infinite;

}

@keyframes gradientShift {
Expand All @@ -78,6 +81,24 @@ body {
}
}

@keyframes colorCycle {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 | Confidence: High

The colorCycle animation is applied to the .animated-gradient element and uses filter properties (hue-rotate and saturate) over a 45‑second infinite loop. filter triggers a full paint of the element and its descendants on every frame, including the ::after pseudo‑element overlay. This will cause continuous GPU composition work and may lead to visible jank, high battery drain, and poor scrolling performance, especially on mobile or lower‑end devices. Additionally, the filter on the parent also modifies the appearance of the overlay (which uses a dark radial gradient), potentially causing unintended color shifts that make the overlay less effective at providing depth.

Code Suggestion:

/* Instead of animating filter, animate background-position or background-size for better performance */
@keyframes colorCycle {
    0% {
      background-position: 0% 50%;
    }
    50% {
      background-position: 100% 50%;
    }
    100% {
      background-position: 0% 50%;
    }
  }
/* Combine with gradientShift if needed, but avoid filter animations */

Evidence: method:colorCycle, search:filter

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick | 🔵 Trivial | 💤 Low value

Use kebab-case for keyframe name.

Stylelint convention expects color-cycle instead of colorCycle for CSS keyframe names.

♻️ Proposed fix
-@keyframes colorCycle {
+@keyframes color-cycle {

Then update the animation reference on line 69:

   animation:
     gradientShift 20s ease infinite,
-    colorCycle 45s ease-in-out infinite;
+    color-cycle 45s ease-in-out infinite;
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
@keyframes colorCycle {
`@keyframes` color-cycle {
🧰 Tools
🪛 Stylelint (17.12.0)

[error] 84-84: Expected keyframe name "colorCycle" to be kebab-case (keyframes-name-pattern)

(keyframes-name-pattern)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@app/globals.css` at line 84, Rename the `@keyframes` declaration named
"colorCycle" to kebab-case "color-cycle" and update any animation references
that use the old name (e.g., where you set animation: colorCycle ...) to the new
"color-cycle" identifier so the keyframe name and all usages match the stylelint
kebab-case convention.

Source: Linters/SAST tools

0% {
filter: hue-rotate(0deg) saturate(1);
}
25% {
filter: hue-rotate(60deg) saturate(1.2);
}
50% {
filter: hue-rotate(120deg) saturate(1.1);
}
75% {
filter: hue-rotate(240deg) saturate(1.2);
}
100% {
filter: hue-rotate(360deg) saturate(1);
Comment on lines 82 to +98

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 Info: colorCycle filter animation creates a new stacking context but is safe here

The new colorCycle animation applies filter: hue-rotate() to .animated-gradient. In CSS, a non-none filter value creates a new stacking context and can cause issues if descendant elements use position: fixed (they'd become relative to the filtered ancestor instead of the viewport). However, this is safe here because .animated-gradient (app/globals.css:53-68) is a standalone position: fixed background div with aria-hidden="true" and no children (except the ::after pseudo-element which is position: absolute). The main content and other UI elements are siblings, not descendants, so the filter won't affect their positioning.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines 82 to +98

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If the colorCycle animation is removed from the background element to improve performance, this @keyframes colorCycle block becomes unused and should be removed to keep the stylesheet clean and maintainable.

/* Keyframes removed */

Comment on lines 82 to +98

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 The two background animations (gradientShift and the new colorCycle) run indefinitely with no reduced-motion guard. The colorCycle animation continuously rotates the hue across the full 360° spectrum, which can be disorienting or physically uncomfortable for users with vestibular disorders — and the prefers-reduced-motion: reduce media query is absent from the entire file. Wrapping the animations so they pause for users who have requested reduced motion follows WCAG 2.3.3 and is a simple addition.

Suggested change
}
@keyframes colorCycle {
0% {
filter: hue-rotate(0deg) saturate(1);
}
25% {
filter: hue-rotate(60deg) saturate(1.2);
}
50% {
filter: hue-rotate(120deg) saturate(1.1);
}
75% {
filter: hue-rotate(240deg) saturate(1.2);
}
100% {
filter: hue-rotate(360deg) saturate(1);
@keyframes colorCycle {
0% {
filter: hue-rotate(0deg) saturate(1);
}
25% {
filter: hue-rotate(60deg) saturate(1.2);
}
50% {
filter: hue-rotate(120deg) saturate(1.1);
}
75% {
filter: hue-rotate(240deg) saturate(1.2);
}
100% {
filter: hue-rotate(360deg) saturate(1);
}
}
@media (prefers-reduced-motion: reduce) {
.animated-gradient {
animation: none;
}
}

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Cursor Fix in Codex Fix in Claude Code Fix in Conductor

}
}
Comment on lines 67 to +100

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎨 Design Review — MEDIUM

Do you think we should provide a reduced-motion variant for the new dual infinite animations, so users who prefer less motion are not forced to view continuous hue/position shifts?

Fix in Cursor | Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖
This is a **Design Review** comment — a question about the UX/design of frontend code. It is intentionally framed as a question, not a prescription. The author may agree or disagree.

**Path:** app/globals.css
**Line:** 67:100
**Comment:**
	*MEDIUM: Do you think we should provide a reduced-motion variant for the new dual infinite animations, so users who prefer less motion are not forced to view continuous hue/position shifts?

- If you agree with the proposal, apply a small, localized change (swap a color token, bump a font size, adjust spacing, add an aria-label, etc.).
- If you disagree, or the answer depends on a design decision a human should make, explain your reasoning and ask the user how to proceed.
Do NOT refactor surrounding components or apply other design changes that weren't asked about.


/* Subtle overlay for depth */
.animated-gradient::after {
content: "";
Expand All @@ -86,7 +107,7 @@ body {
background: radial-gradient(
ellipse at center,
transparent 0%,
rgba(0, 0, 0, 0.3) 100%
rgba(0, 0, 0, 0.15) 100%
);
pointer-events: none;
}
Expand All @@ -97,15 +118,16 @@ body {

.coming-soon-card {
position: relative;
background: rgba(30, 41, 59, 0.25);
backdrop-filter: blur(40px);
-webkit-backdrop-filter: blur(40px);
border: 1px solid rgba(148, 163, 184, 0.15);
background: rgba(255, 255, 255, 0.18);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: Using a highly translucent white background (rgba(255, 255, 255, 0.18)) over the bright, colorful animated gradient makes white text (#ffffff) and light secondary text (#cbd5e1) difficult to read, likely violating WCAG 4.5:1 contrast requirements. The dynamic hue-rotating gradient makes contrast unpredictable. Consider using a dark translucent background (e.g., rgba(15, 23, 42, 0.6)) with a subtle white border to maintain legibility while preserving the glassmorphism aesthetic.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/globals.css, line 119:

<comment>Using a highly translucent white background (`rgba(255, 255, 255, 0.18)`) over the bright, colorful animated gradient makes white text (`#ffffff`) and light secondary text (`#cbd5e1`) difficult to read, likely violating WCAG 4.5:1 contrast requirements. The dynamic hue-rotating gradient makes contrast unpredictable. Consider using a dark translucent background (e.g., `rgba(15, 23, 42, 0.6)`) with a subtle white border to maintain legibility while preserving the glassmorphism aesthetic.</comment>

<file context>
@@ -97,15 +116,16 @@ body {
-  backdrop-filter: blur(40px);
-  -webkit-backdrop-filter: blur(40px);
-  border: 1px solid rgba(148, 163, 184, 0.15);
+  background: rgba(255, 255, 255, 0.18);
+  backdrop-filter: blur(60px);
+  -webkit-backdrop-filter: blur(60px);
</file context>
Suggested change
background: rgba(255, 255, 255, 0.18);
background: rgba(15, 23, 42, 0.6);

backdrop-filter: blur(60px);
Comment on lines 119 to +122

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Using a highly translucent white background (rgba(255, 255, 255, 0.18)) for the card over a bright, colorful gradient background makes the white text (#ffffff) and light secondary text (#cbd5e1) extremely difficult to read, violating WCAG accessibility guidelines for contrast.

To ensure readability and maintain a beautiful glassmorphism effect, consider using a dark translucent background (e.g., rgba(15, 23, 42, 0.6)) with a subtle white border. This provides excellent contrast for light text while still letting the colorful background gradient blur through beautifully.

Suggested change
.coming-soon-card {
position: relative;
background: rgba(30, 41, 59, 0.25);
backdrop-filter: blur(40px);
-webkit-backdrop-filter: blur(40px);
border: 1px solid rgba(148, 163, 184, 0.15);
background: rgba(255, 255, 255, 0.18);
backdrop-filter: blur(60px);
background: rgba(15, 23, 42, 0.6);
backdrop-filter: blur(40px);
-webkit-backdrop-filter: blur(40px);
border: 1px solid rgba(255, 255, 255, 0.15);

-webkit-backdrop-filter: blur(60px);
Comment on lines +120 to +121

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of backdrop-filter: blur(60px); and -webkit-backdrop-filter: blur(60px); in the .coming-soon-card class can cause significant performance degradation, especially on lower-end devices or browsers with limited hardware acceleration. Consider reducing the blur radius or providing a fallback for environments where backdrop-filter is not well supported.

border: 1.5px solid rgba(255, 255, 255, 0.35);
border-radius: 2.5rem;
text-align: center;
box-shadow:
0 20px 40px -10px rgba(0, 0, 0, 0.2),
0 0 0 1px rgba(255, 255, 255, 0.08) inset;
0 25px 80px -15px rgba(0, 0, 0, 0.2),
0 0 0 1px rgba(255, 255, 255, 0.3) inset,
0 0 40px rgba(99, 102, 241, 0.1);
Comment on lines 125 to +128

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiple large box-shadows applied to .coming-soon-card may negatively impact rendering performance, particularly on mobile devices. Consider simplifying the box-shadow or using fewer layers to improve performance while maintaining visual depth.

transition: all 0.4s cubic-bezier(0.4, 0, 0.2, 1);
/* Rectangle: wider than tall for hero feel */
width: clamp(300px, min(85vw, 85vh), 580px);
Expand All @@ -119,11 +141,12 @@ body {
}

.coming-soon-card:hover {
background: rgba(30, 41, 59, 0.35);
border-color: rgba(148, 163, 184, 0.25);
background: rgba(255, 255, 255, 0.22);
border-color: rgba(255, 255, 255, 0.45);
box-shadow:
0 20px 40px -10px rgba(99, 102, 241, 0.15),
0 0 0 1px rgba(148, 163, 184, 0.15) inset;
0 30px 100px -15px rgba(99, 102, 241, 0.25),
Comment on lines 142 to +147

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If the card's base background is updated to a dark translucent style to improve text contrast, the hover state should be updated accordingly to maintain visual consistency.

Suggested change
.coming-soon-card:hover {
background: rgba(30, 41, 59, 0.35);
border-color: rgba(148, 163, 184, 0.25);
background: rgba(255, 255, 255, 0.22);
border-color: rgba(255, 255, 255, 0.45);
box-shadow:
0 20px 40px -10px rgba(99, 102, 241, 0.15),
0 0 0 1px rgba(148, 163, 184, 0.15) inset;
0 30px 100px -15px rgba(99, 102, 241, 0.25),
background: rgba(15, 23, 42, 0.7);
border-color: rgba(255, 255, 255, 0.25);
box-shadow:
0 30px 100px -15px rgba(99, 102, 241, 0.3),
0 0 0 1.5px rgba(255, 255, 255, 0.2) inset,
0 0 60px rgba(99, 102, 241, 0.2);

0 0 0 1.5px rgba(255, 255, 255, 0.4) inset,
0 0 60px rgba(99, 102, 241, 0.15);
}

@media (max-width: 768px) {
Expand Down Expand Up @@ -159,17 +182,13 @@ body {
font-weight: 700;
letter-spacing: -0.02em;
line-height: 1.2;
color: var(--text-primary);
color: #ffffff;
margin-bottom: 1.25rem;
background: linear-gradient(
135deg,
var(--accent-light) 20%,
var(--accent) 80%
);
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
background-clip: text;
opacity: 0.95;
text-shadow:
0 0 30px rgba(255, 255, 255, 0.3),
0 0 60px rgba(99, 102, 241, 0.2),
0 2px 10px rgba(0, 0, 0, 0.2);
opacity: 1;
}

@media (max-width: 768px) {
Expand Down Expand Up @@ -283,9 +302,9 @@ body {

.language-selector select {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

When styling a <select> element with a light translucent background and light text, some browsers (like Chrome/Firefox on certain operating systems) will render the dropdown options (<option>) with a default light background while inheriting the light text color, making the options completely invisible or unreadable.

To ensure cross-browser compatibility and readability, explicitly style the option elements with a solid, dark background.

Suggested change
.language-selector select {
background: rgba(255, 255, 255, 0.12);
& option {
background-color: #1a1f35;
color: var(--text-primary);
}

appearance: none;
background: rgba(30, 41, 59, 0.5);
backdrop-filter: blur(12px);
-webkit-backdrop-filter: blur(12px);
background: rgba(255, 255, 255, 0.12);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: When styling a <select> with a translucent background and light text (color: var(--text-primary)), some browsers render dropdown <option> elements with a default light background while inheriting the light text color, making options invisible or unreadable. Explicitly style the option elements with a solid dark background to ensure cross-browser readability:

.language-selector select option {
  background: #1a1f35;
  color: #f1f5f9;
}
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/globals.css, line 303:

<comment>When styling a `<select>` with a translucent background and light text (`color: var(--text-primary)`), some browsers render dropdown `<option>` elements with a default light background while inheriting the light text color, making options invisible or unreadable. Explicitly style the `option` elements with a solid dark background to ensure cross-browser readability:

```css
.language-selector select option {
  background: #1a1f35;
  color: #f1f5f9;
}
```</comment>

<file context>
@@ -283,9 +300,9 @@ body {
-  background: rgba(30, 41, 59, 0.5);
-  backdrop-filter: blur(12px);
-  -webkit-backdrop-filter: blur(12px);
+  background: rgba(255, 255, 255, 0.12);
+  backdrop-filter: blur(20px);
+  -webkit-backdrop-filter: blur(20px);
</file context>

backdrop-filter: blur(20px);
-webkit-backdrop-filter: blur(20px);
border: 1px solid var(--border-default);
border-radius: 0.75rem;
padding: 0.5rem 2.5rem 0.5rem 1rem;
Expand All @@ -295,12 +314,12 @@ body {
cursor: pointer;
transition: all 0.2s ease-in-out;
min-width: 120px;
background-color: rgba(30, 41, 59, 0.5);
}

.language-selector select:hover {
border-color: var(--accent);
background: rgba(30, 41, 59, 0.6);
background: rgba(255, 255, 255, 0.18);
box-shadow: 0 0 20px rgba(99, 102, 241, 0.2);
}

.language-selector select:focus {
Comment on lines 314 to 325

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accessibility Concern: Custom Select Styling

The .language-selector select element is heavily styled, which can sometimes interfere with native accessibility features, especially for keyboard and screen reader users. Ensure that the select element remains fully accessible and that custom styling does not obscure focus indicators or reduce usability for assistive technologies.

Recommendation:

  • Test the select element with keyboard navigation and screen readers.
  • If replacing the native arrow, ensure the custom arrow (created with .language-selector::after) does not interfere with click or focus events.
  • Consider adding aria-label or aria-labelledby attributes if the select lacks a visible label.

Expand Down
Loading