<filename>Report/thesis/content/introduction.tex
%!TEX root = ../thesis.tex


\section{Motivation Stichpunkte}

Anstatt rich-text mit dem Begriff ''Gestaltete Texte'' anfangen. Sagen es ist ein Kulturwerkzeug. Betonen dass  rich-text im Internet so wichtig ist weil über das Internet Texte global verbreitet werden können.

Text editing ist wichtig: Transportiert das wissen Menschheit über Generationen.
Rich text editing spielt eine Rolle, texte mit Bildern und Formatierungen sagen mehr als reiner text. Keine Zeitung würde ohne Bilder und Layouting funktionieren.
Computer sind schon längst das Mittel um rich text zu erzeugen.
Auf lokalen Maschinen ist das schon längst kein Problem mehr.
Allerdings werden Desktop Anwendungen immer mehr von Web- und vor allem Browser-basierten Anwendungen abgelöst.
Dies hat viele Vorteile:
 - Die Programme können zentral gewartet werden und alle Rechner verwenden automatisch die neueste Version.
 - Auf die Programme kann von überall aus zugegriffen werden.
 - Inhalte können zusammen geteilt und bearbeitet werden.
Dennoch ist rich text editing im Internet nicht wirklich einfach möglich.
Browser bieten APIs an, die dafür gemacht sind rich-text Editoren zu implementieren
Diese APIs sind sehr limitiert, inkonsistent und verbuggt.
Das führt dazu dass Web Entwickler nicht einfach einen Editor programmieren können, sondern auf fertige Editoren dritter zurückgreifen müssen. Diese passen nicht unbedingt zu den eigenen Ansprüchen.
Die limitierten Features erlauben es nur einfache Editoren zu implementieren. Ein komplexer Editor wie Google's document Editor lässt sich mit diesen APIs nicht umsetzen, weswegen Google diese API auch nicht verwendet hat. 
Es gibt aber keine Library und so gut wie keine Editoren die rich-text editing ohne editing APIs möglich machen.
 - Ich möchte eine rich text library implementieren die ohne diese Browser APIs auskommt, was ein konsistentes verhalten über verschiedene Browser erlaubt, mehr Möglichkeiten/Features bietet und die unzähligen Bugs und Probleme umschifft.
 - Ich möchte das ganze als reine Software-Bibliothek anbiete, die alle Methoden mit einer high-level API einfach zugänglich macht und die Implementierung des editors, also user interfaces, in die Hand des Web Entwicklers gebe.
= Somit soll Web-Entwicklern erstmalig die Möglichkeit gegeben werden, schnell und einfach selber Feature-reiche Editoren zu implementieren, so wie sie sie selber in ihrem Projekt brauchem, was jetzt einfach nicht möglich ist.


% - Ich rich text editing durch direkte manipulation der Webseite mit DOM Level 1 APIs realisiere ohne die 
% - Ich andere APIs verwende, als die, die die Browser für rich text editing vorsehen um die selbe Funktionalität zu erreichen.
% Browser bieten nur eine sehr verbugte und limitierte Möglichkeit an einen rich text editor zu implementieren.
%Als Webentwickler muss ich auf fertige Editoren dritter zurück greifen und mich den Grenzen dieser Editoren beugen.



\section{Motivation}

\paragraph{Detlev} Rich text ist sauwichtig (geschichte, lulturgut). So was wie google docs ist im moment NICHT MÖGLICH. Wegen contenteditable. Ich ändere das.

AUSSERDEM KEIN EDITOR SONDER EINE LIBRARY ganz tolles feature und wichtiger Punkt

hier auch irgendwo sagen dass ich ne library schreibe **und sie type nenne**

Rich-text editors are commonly used by many on a daily basis. Often, this happens knowingly, for instance in an office suite, when users willfully format text. But often, rich-text editors are being used without notice. For instance when writing e-mails, entering a URL inserts a link automatically in many popular e-mail-applications. Also, many applications, like note-taking apps, offer rich-text capabilities that go unnoticed. Many users do not know the difference between rich-text and plain-text writing. Rich-text editing has become a de-facto standard, that to many users is \textit{just there}. Even many developers do not realize that formatting text is a feature that needs special implementation, much more complex than plain-text editing.

While there are APIs for creating rich-text input controls in many desktop programming environments, web-browsers do not offer native rich-text inputs. However, third-party JavaScript libraries fill the gap and enable developers to include rich-text editors in web-based projects.

The libraries available still have downsides. Most importantly, only a few of them work. As a web-developer, the best choices are either to use CKEditor or TinyMCE. Most other editors are prone to bugs and unwanted behavior. <NAME>\'{n}ski, core developer of CKEditor comments this on StackOverflow as follows:

\begin{quotation}
\textit{''Don't write wysiwyg editor[sic] - use one that exists. It's going to consume all your time and still your editor will be buggy. We and guys from other... two main editors (guess why only three exist) are working on this for years and we still have full bugs lists ;). \cite{sopp}''}
\end{quotation} %\footnote{\url{http://stackoverflow.com/questions/11240602/paste-as-plain-text-contenteditable-div-textarea-word-excel/11290082#11290082}, last checked on 07/13/2015}

A lot of the bugs CKEditor and other editors are facing are due to the fact that they rely on so-called ''HTML Editing APIs'' that have been implemented in browsers for years, but only been standardized with HTML5. Still, to this present day, the implementations are prone to numerous bugs and behave inconsistently across different browsers. And even though these APIs are the de-facto standard for implementing rich-text editing, with their introduction in Internet Explorer 5.5, it has never been stated they have been created to be used as such.

It is a fact, that especially on older browsers, rich-text editors have to cope with bugs and inconsistencies, that can only be worked around, but not fixed, as they are native to the browser. On the upside, these APIs offer a high-level API to call so-called ''commands'' to format the current text-selection. 

However, calling commands will only manipulate the document's DOM tree, in order to format the text. This can also be achieved without using editing APIs, effectively avoiding unfixable bugs and enabling a consistent behavior across all browsers.

Furthermore CKEditor, TinyMCE and most other libraries are shipped as user interface components. While being customizable, they tend to be invasive to web-projects.

This thesis demonstrates a way to enable rich-text editing in the browser without requiring HTML Editing APIs, provided as a GUI-less software library. This enables web-developers to implement rich-text editors specific to the requirements of their web-projects.

\textit{Rich-text editing on the web is a particularly overlooked topic. Most libraries use contenteditable without questioning its benefits. The literature on this topic is thin. It is rarely written about in books and papers and no one really examines alternative ways for implementation. ACE and CodeMirror show techniques how to do it. However looking at its history, it seems very questionable. People who implement editors using it often rant about its disadvantages. <- der letzte Satz sollte einer der kernpunkte der introduction sein. Überahupt, das questioning sollte im kern stehen. SCHREIBEN DASS AUCH ANDERE WIE MEDIUM DARÜBER RAGEN, SOWIESO MEHR REFERENZEN FINDEN}

\paragraph{detlev} Warum textverarbeitung im Web? - 1 applikation auf allen systemem anstatt 1000 programme und versionen, weniger wartbar aufwändiger - weltweit verfügbar - gebackupped durch hosting und cloud - und wirtschaftlich zentral verwetbar. - probleme der pirvatsphäre sind nicht teile dieser arbeit.

\section{Terminology}

In the web-development world, the term \textit{WYSIWYG} editor is commonly used. WYSIWYG is an abbreviation for \textbf{W}hat \textbf{Y}ou \textbf{S}ee \textbf{I}s \textbf{W}hat \textbf{Y}ou \textbf{G}et and describes a text editor's capability to display formatted text as it is being edited. This stands out to plain-text editors that can neither display nor edit formattings. The term rich-text editor has often been used for this feature and is more precise. For this reason, the term \textit{rich-text editor} and \textit{rich-text editing} will be used in this thesis.

%rich-text, WYSIWYG, word-processing, WYSIWYM

\section{Structure}

The first part of this thesis explains rich-text editing on desktop PCs. The second part explains how rich-text editors are currently being implemented in a browser-environment and the major technical differences to the desktop. Part three will cover the downsides and the problems that arise with the current techniques used. Part four will explain how rich-text editing can be implemented on the web bypassing these problems. Part five dives into the possibilities of web-based rich-text editing in particular when using the techniques explained in this thesis.

%% possibilites
%% * collaboration with etherpad
%% * Markdown

% desktop -> caret selection etc -> contenteditable not necessary ->
% we will see that contenteditable handles all this, but in my solution this all needs to be coded again
% I need to discuss that the benefits are bigger than having to do this