Activity breaks CSS `:has()` rules

Why this is a good first issue

CSS `:has()` rules are incorrectly applied due to `display: none` behavior.

AI Summary

The issue involves CSS `:has()` rules being incorrectly applied during navigation due to `display: none` behavior. A potential solution involves adding a `hidden` attribute to elements, but this may introduce side effects. The scope is somewhat clear but requires careful handling of CSS specificity and potential side effects.

Issue Description

Link to the code that reproduces this issue

https://github.com/binarystride/next-activity-has-repro

To Reproduce

Enabled Cache Components
Add a :has() CSS rule to your layout that targets page A content
Go to page A and then navigate to page B

Current vs. Expected behavior

Expected: page B does not apply :has() rule

Current: page B applies :has() rule

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041
  Available memory (MB): 24576
  Available CPU cores: 12
Binaries:
  Node: 22.21.1
  npm: 10.9.4
  Yarn: 1.22.22
  pnpm: 9.15.4
Relevant Packages:
  next: 16.1.6 // Latest available version is detected (16.1.6).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

cacheComponents

Which stage(s) are affected? (Select all that apply)

next dev (local), next start (local), Vercel (Deployed), Other (Deployed)

Additional context

This happens because on navigation Activity hides the previous page content with display: none but :has() rule still targets it because it does not care about display: none style. I know of one workaround where the CSS rule is configured to skip elements with display: none but that seems hacky to me and may break in the future.

If Next.js could add a stable attribute like hidden or something similar to the hidden element, the :has() rule would be easier to write and less likely to break.

Do you have any other recommendations or the current workaround is actually good enough?

To be honest this is not exactly a bug, so feel free to move to discussion if that's more appropriate.