Feature Wiki
Tabs
Suggestions for an Improved ILIAS Page Editor (outdated)
Page Overview
[Hide]- 1 Initial Problem
- 1.1 Current Implementation
- 1.1.1 Data Structure
- 1.1.2 Separation of Content Structure and Style
- 1.1.3 How editing works
- 1.2 Current Issues/Problems
- 1.1 Current Implementation
- 2 Conceptual Summary
- 2.1 Using a contentEditable based solution
- 2.2 Using a DOM Manipulating based solution
- 2.3 Alternatives
- 2.3.1 TinyMCE
- 2.3.2 CKEditor
- 2.3.3 ProseMirror
- 2.4 Related Feature Requests
- 3 Status
- 4 Additional Information
- 5 Discussion
- 6 Implementation
This page is maybe not what you are looking for. Please consult New ILIAS Page Editor.
1 Initial Problem
1.1 Current Implementation
1.1.1 Data Structure
The ILIAS page editor stores its content as well defined structured XML. A DTD defines the structure of this XML. For example for ILIAS 5.1 this DTD can found under xml/ilias_pg_5_1.dtd
.
<PageObject Language="-" Active="1" ActivationStart="" ActivationEnd="" ShowActivationInfo="0"> |
The XML is now being transformed into HTML using an XSLT (transformation processing). The result looks (simplified) like this:
<div class="ilc_page_cont_PageContainer"> |
1.1.2 Separation of Content Structure and Style
When editing authors cannot directly assign style attributes (e.g. font color, font size, ...) to the content. The editor provides only the possibility to assign style classes to text or content elements. A separate CSS editor allows to define the styles for these classes. The main reasons are:
- The separation of content style allows to attribute style classes with a title that says something about the semantics / meaning of this style class. For example a section could use the style class "Further Reading" or "Advanced Content". This gives authors a guide when to use this style.
- The use of style classes allows to apply styles consistently. This consistency greatly improves the learnability for the reader. It will be easy to understand what a certain style means and identify corresponding elements quickly in the content.
- The use of style classes centralizes style decisions in the style sheet. This greatly improves maintainability of the style, since it allows to make consistent changes in one place. If styles are directly assigned to the content on each page separately, it will need much more effort to make changes consistently.
- The style sheets also work as an inventory of styles. If style attributes could be applied directly to content it would be impossible to get an overview which kind of style attributes are used at all (e.g. in a learning module). Only the style editor allows to develop and implement a global (or local) style guide at all.
- The centralisation of the style decision also allows to put design decision into the hand of professional designers will result in a general better quality of the applied styles.
1.1.3 How editing works
Initially the whole editor used HTML forms and BB-Code like syntax for text elements. Like today the whole editing page is devided into blocks, each block represents a content element of different types (e.g. text paragraph, sections, file lists, ...). Blocks can be moved around (today using JS and drag/drop), but if the content of a block should be edited (e.g. a text paragraph) a switch into the "editing view" of a single block is necessary.
- Most blocks still use simple HTML forms in a separate view to edit the attributes of the block.
- Editing of text blocks is using an instance of the TinyMCE editor in the background. Since TinyMCE is an HTML editor a transformation from the HTML output of TinyMCE to our XML is needed. Since the output of HTML editors like TinyMCE depends to a certain extent on the browser, this is already an error-prone task. Even if things have been improved in the past.
1.2 Current Issues/Problems
Killing, Alexander [alex], 15 Sep 2016: Everyone is invited to list her or his issues with the current editor. I know that the requirements are quite diverse.
- All paragraphs are handled separately. It requires a lot of clicking to write down heading-text-sequences.
- Bugs mainly due to browser/Tiny behaviour, e.g. when editing nested lists.
- Annoying editing of tables, especially large tables.
- Adding images or youtube videos uses a quite complex form/workflow.
2 Conceptual Summary
In general we do not want to break the already available content. This means we keep the underlying well-defined-XML structure for the page editor including a semantic content attribution approach and a separation of semantic content structure and style. There are currently two approaches when it comes to content editing in web browsers. Using the contentEditable feature of browsers or providing a complete editing environment on top of the DOM.
2.1 Using a contentEditable based solution
The most popular wysiwyg HTML editors make use of contentEditable attribute for elements which activates the browser support for editing element. The underlying problem is the very different support of browsers for this feature, differences in resulting markup, selection/cursor handling, and so on. This results in difficulties when mapping the different results to a well-defined document structure.
2.2 Using a DOM Manipulating based solution
This approach catches all events fired by the user (pressing buttons, pasting content, ...) before the browser executes them. Instead of the browser own-written-Javascript now applies the necessary changes to the DOM directly. Google Docs does this (its editor is not open source).
2.3 Alternatives
2.3.1 TinyMCE
- Inline Editing
- Premium features, e.g. Paste From Word
- Non-Editable Plugin (May allow at least partially implementing the behaviour of CK Editor widgets, documentation says "editable in noneditable" is not supported. This example seems to work at least in current Firefox version.)
2.3.2 CKEditor
2.3.3 ProseMirror
ProseMirror uses the contenteditabl feature for cursor and selection handling only. All other events are catched and executed by its own code.
- currently beta (15 Sep 2016)
- reliable content structure results
- provides historical position mapping (interesting, e.g. when it comes to annotate selections)
- collaboration support (handles conflicts when multiple users are editing the same content)
- support for widgets or at least non-editable areas
- flexibility in the definition of the target document structure
2.4 Related Feature Requests
Several existing feature requests are related to or dependent from the further decision about the technical basis of the ILIAS Page Editor. These requests are listed below:
3 Status
- Scheduled for: Not scheduled yet
- Funding: [[Required]
- Maintainer: Alexander Killing, LEIFOS
- Implementation of the feature is done by (company, developer)
- Contract settled: No
- Tested by / status: (name, e-mail), (status information set after implementation)
4 Additional Information
Contact the following persons if you want to know more about this feature, its implementation or funding:
- Information about concept: Alexander Killing, LEIFOS
- Information about funding: (name, e-mail)
- Information about implementation: (name, e-mail)
5 Discussion
6 Implementation
...
Last edited: 16. Nov 2023, 17:00, Tödt, Alexandra [atoedt]