Is there any public discussion that I could read through on why this non-standard Electron-only CSS property is enabled by default? It seems like an odd choice when File.path was removed because it was non-standard and the non-standard <webview> tag is disabled by default. Was it just a mistake that it is enabled by default or has Electron's policy on not adding non-standard stuff changed?

@absidue First off, thanks for the feedback! That is a great question to raise. I've thought about this a lot during this feature's development.

The design & rationale for this feature was captured in RFC 12 and its corresponding PR. The non-standard-ness was a point of discussion I proactively brought up in the RFC text and during the API Working Group meetings.

Your question about consistency with other non-standard APIs is fair to ask. Our thinking was based on precedent, ergonomic design, and risk assessment:

• Electron does support specific non-standard CSS properties when they solve a platform need. The best example is -webkit-app-region¹, commonly used for specifying custom draggable regions. While this property is implemented in Chromium², its modern use is almost exclusively for Electron apps. Adding another targeted non-standard property (with appropriate standard-supported vendor prefixing) didn't feel like a departure from this practice.

• From an ergonomic standpoint, we want features to have minimal friction (unless there is a significant concern with its safety, of course). If this property were disabled by default, developers wanting to use it would have to enable a flag before they can use it. By enabling it by default, developers who want it can simply use the CSS property, and those who don't can simply avoid it. Adding an extra configuration step (a "speedbump") for developers wasn't justified without a high-risk drawback.

• You're right that File.path and <webview> were removed/disabled in part due to being non-standard. However, their primary issues were severe security and privacy risks: File.path could expose sensitive data (usernames and confidential project names); <webview> had significant security implications. While the corner smoothing property does introduce a fingerprinting vector (a valid privacy concern!), we judged its risk to be in a different, lower class than the others.

To directly answer your last question: Electron's policy on avoiding non-standard APIs hasn't changed. We still weigh the purpose and utility of a feature against its drawbacks—security, privacy, and non-standard-ness. In this case, we felt the feature was an appropriate addition to the platform.

All that said, we're open to revisiting this decision. You're one of the first people to reach out to me about this topic, so if you feel the trade-off isn't right and have a motivating explanation for why corner smoothing should be disabled by default, then please feel free to open a new discussion issue!

Release Notes Persisted

Fixed a crash when adding the -electron-corner-smoothing CSS rule to a stylesheet with no associated document.

I was unable to backport this PR to "37-x-y" cleanly;
you will need to perform this backport manually.

I have automatically backported this PR to "38-x-y", please check out #47785

@clavin has manually backported this PR to "37-x-y", please check out #47792