Bug: createRoot function from React@18 break the css :target

[magic-akari]

Keywords

• React 18
• createRoot
• CSS selector
• CSS Target
• :target

React version: React@18

Steps To Reproduce

1. open https://joyful-kelpie-c3bb20.netlify.app/buggy.html
2. click go to react id target link
3. You should see the react id target with green background
4. Refresh page. The green background disappears

Link to code example:

The webpage source code is simple. You could check the source code directly.

Or, you can check this:
https://gist.github.com/magic-akari/475a13219394fb938cff4169a9b61eb7

The current behavior

CSS target selector does not work.
The green background disappears after refresh pages.

The expected behavior

CSS target selector should work after refresh pages.

See: https://joyful-kelpie-c3bb20.netlify.app/ok.html

[Almas456]

Change in rendering behavior: The createRoot function is a new API introduced in React@18 that changes the way that React renders components. If your application relies on specific rendering behavior, this change could potentially cause CSS issues.

SSR/CSR mismatch: If your application uses server-side rendering (SSR) and client-side rendering (CSR), using the createRoot function could potentially cause a mismatch between the SSR and CSR versions of your application, leading to CSS issues.

Other changes in React@18: React@18 introduces several other changes and improvements to the React library, including updates to the reconciliation algorithm and improved error handling. These changes could potentially cause unexpected behavior in your application, including CSS issues.

To help identify the root cause of the issue, I would recommend the following steps:

Check the React@18 release notes: The React@18 release notes provide a detailed overview of the changes and improvements introduced in this version of React. Check the release notes to see if any of the changes are related to the CSS issue you are experiencing.

Check for known issues: There may be known issues or bugs related to the createRoot function that are causing the CSS issue you are experiencing. Check the React issue tracker or forums to see if others are reporting similar issues.

Check your code: Review your code to see if there are any potential issues related to the createRoot function, such as SSR/CSR mismatch or reliance on specific rendering behavior.

Create a minimal reproduction: If you are still unable to identify the root cause of the issue, create a minimal reproduction of the problem and share it with the React community. This will help others to understand the issue and potentially identify a solution.

[magic-akari]

@Almas456 Thank you for your response, but it is not helpful.

I have reviewed the React@18 release notes, but there was no mention of CSS issues in the createRoot function section.

I searched for existing issues before submitting this one, and did not find any relevant information.
Therefore, I included some keywords in this issue to help future searchers find it easily. So please do not doubt that I have not done my research thoroughly.

I have provided a minimum reproducible example and detailed the steps to reproduce the issue.

Lastly, may I ask if this reply was generated by a machine like ChatGPT?
It seems to be too generic and lacks specificity and relevance to this particular issue.

[no-yan]

I've tested it in Chrome, Firefox, and Safari.
Chrome and Safari show reported behavior, and Firefox doesn't. The same goes for any Canary.

Just for convenience, the main difference between ok.html and buggy.html is shown below.

-     ReactDOM.render(
-       React.createElement(App),
-       document.querySelector("#root")
-     );
+     const rootElement = document.querySelector("#root");
+     const root = ReactDOM.createRoot(rootElement);
+     root.render(React.createElement(App));

[magic-akari]

I've tested it in Chrome, Firefox, and Safari. Chrome and Safari show reported behavior, and Firefox doesn't. The same goes for any Canary.

Just for convenience, the main difference between ok.html and buggy.html is shown below.

-     ReactDOM.render(
-       React.createElement(App),
-       document.querySelector("#root")
-     );
+     const rootElement = document.querySelector("#root");
+     const root = ReactDOM.createRoot(rootElement);
+     root.render(React.createElement(App));

I did not take notice of the behavior of Firefox.
Thank you for your research.

[Okhan97]

Any updates on this?
I tried to implement it in my company's project and it completely broke in safari (chrome works fine).
Inspecting the element shows the body empty, somewhere I read that this change might break some css and that may cause a huge problem when SSR and CSR don't match.

Sadly I lost a lot of time trying to fix this issue, looks like following "the best practice" is not always the best choice ☹️

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[magic-akari]

bump

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[magic-akari]

bump

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[magic-akari]

bump

[magic-akari]

It can still be replicated in React@19.

[plocket]

I've seen the same behavior. An issue I found that seems similar to me was remix-run/history#503 , but history state is a bit new to me and I'm not sure if it's related.

I checked the source and it calls window.history.pushState with the new URL when history API is available, which doesn't seem to trigger the :targer selector.

Edit:
From other searching, it looks like this may be related to this whatwg issue: whatwg/html#639 (comment). It seems like they're going to keep it that way.