Why not on-page editing?

Some of you might be familiar with on-page editing. Editors find it simple and intuitive to click the content they want to change on the page and edit it directly on the page. The reason why we have chosen another path are mainly these.

1. To get on-page editing to work, the CMS needs to add functions not supported by any web standard, and we, as a vendor, must invent solutions that might conflict with your Accessibility Guidelines (WCAG) and other web standards.
2. When creating on-page editing support, the CMS adds extra (unnecessary) code to your website, making it difficult to obtain a fast website with excellent performance.
3. Because the CMS adds extra code to your website, the preview of the website is not a "what you see is what you get" experience.
4. On-page editing works well for demo-purpose with a scenario optimized for the simplest tasks. On-page editing is difficult to support for more complex tasks.
5. In the headless context, there might be documents with no public presentation. We need a solution that fits any editing scenario to keep the editing consistent for any editing task.
6. We wish to be a developer-friendly CMS, and we want a developer to be able to build everything that you, as an editor, need to get your work done. Adding unnecessary code makes it harder to accomplish this and might add many extra costs when upgrading your CMS to a later version because of breaking changes.