Differences

This shows you the differences between two versions of the page.

--- en:why [2018/07/30 11:23] – Andreas Gohr
+++ en:why [2018/07/30 11:25] (current) – Andreas Gohr
@@ Line 1: / Line 1: @@
 ======= Why a new WYSIWYG plugin? ======
-A [[https://www.dokuwiki.org/plugins?plugintag=wysiwyg#extension__table|series of plugins]] attempting to integrate a WYSIWYG editor into DokuWiki. [https://www.dokuwiki.org/plugin:ckgedit|CKGEdit]] maintained by Myron Turner is probably the most popular.
+There are a [[https://www.dokuwiki.org/plugins?plugintag=wysiwyg#extension__table|series of plugins]] that attempt to integrate a WYSIWYG editor into DokuWiki. [[https://www.dokuwiki.org/plugin:ckgedit|CKGEdit]] maintained by Myron Turner is probably the most popular.
 To understand why the approach of CKGEdit and similar plugins is not ideal for wikis, we need to take a deeper look at the details...
@@ Line 13: / Line 13: @@
 WYSIWYG editors have a different approach. They allow you to edit the HTML code directly. But not as raw HTML code, but as WYSIWYG. In concrete terms, this means that rendered HTML is directly manipulated. Since HTML is complex and browsers are actually meant to be display machines, the development of such an editor is already relatively complex, even if one has "only" HTML as input and output format.
-For wikis there is another hurdle: you want to give experienced users the possibility to continue using Wiki syntax((In fact, some wikis, such as Confluence, have completely abandoned this claim and now only offer a WYSIWYG editor -- content is simply saved as HTML
+For wikis there is another hurdle: you want to give experienced users the possibility to continue using Wiki syntax((In fact, some wikis, such as Confluence, have completely abandoned this aspiration and now only offer a WYSIWYG editor -- content is simply saved as HTML
 )). This means there has to be a conversion back and forth between HTML and Wiki syntax. From Wiki syntax to HTML this is simple, the other direction is more complicated: a complex system must be meaningfully converted into a less complex one.
-{{ :traditional.png?400 |The traditional WYSIWYG approach}}}
+{{ :traditional.png?400 |The traditional WYSIWYG approach}}
 The traditional approach quickly reaches its limits: what if I insert a red text (for example, using Copy'n'Paste) into the WYSIWYG editor? Red text is valid HTML and is first displayed as such by the browser. However on saving to wiki syntax, the red will be lost of course. That means I no longer have a true "What you see is what you get" Editor anymore. I see red text, but I get black text.
@@ Line 22: / Line 22: @@
 This means that the editor itself has to know exactly what the Wiki system behind it can do in order to limit the input accordingly.
-This is exactly the approach the [https://prosemirror.net/|Prosemirror]] toolkit takes. Prosemirror is a library that provides the basic mechanisms for a WYSIWYG editor, but makes no assumptions about the input and output format. Instead, the editor works internally with an abstract model of the edited document. A schema defines how this document can be structured.
+This is exactly the approach the [[https://prosemirror.net/|Prosemirror]] toolkit takes. Prosemirror is a library that provides the basic mechanisms for a WYSIWYG editor, but makes no assumptions about the input and output format. Instead, the editor works internally with an abstract model of the edited document. A schema defines how this document can be structured.
 The editor converts the document to HTML for display and returns user input back to the document. When saving, the abstract document is converted back into syntax - since the schema already ensures that the document is well-formed, this last step is comparatively trivial.