WYSIWYG HTML editor in the browser. Part 1
This is the first part of the translation of an article about the designMode and contentEditable properties, their behavior and features.
The article discusses the basic principles and problems of unifying the features of editing in modern browsers. Topics covered in the article:
In the very first browser created by Tim Bernes-Lee in 1990, web pages could be edited directly in the browser in WYSIWYG mode. The web was viewed as a readable and writable medium. Later browsers, however, basically allowed only readable information, except that text could be entered into form input fields.
WYSIWYG editing in the browser again became the norm with the release of Internet Explorer 5: the new designMode property allowed the user to edit the entire document. At first, this feature was somehow overlooked, possibly due to the fact that it appeared along with a host of other non-standard, proprietary capabilities of IE available only under Windows OS.
')
In recent years, other competing browsers — Mozilla, Safari, and Opera ( translator’s note: Chrome has not yet appeared at the time of this writing. The first beta will be released in just a few months. ) - they followed the example of IE and also implemented this feature. WHATWG is working on standardizing the editing mode - the designMode and contentEditable properties are presented in HTML 5. It seems that browser WYSIWYG editing is still becoming an integral part of the web.
The article discusses the basic principles and problems of unifying the features of editing in modern browsers. Topics covered in the article:
Note: I only consider editing features in browsers: Opera 9.5, Firefox 2+ and Safari 3, since in previous versions the editors were too buggy and incomplete. And the editor in IE has hardly changed since version 5.5)))
Edit mode makes the page or part of it editable. This is expressed in that:
There are two ways to enable editing mode - the designMode and contentEditable properties.
A window or frame becomes editable by setting the document's designMode property of the document to true. (Disclaimer: In IE, you need to get a link to the document from the window object.) Typically, an editable block is created using an IFrame and designMode.
Any element containing text can be made editable by setting the contentEditable property to true. (ContentEditable is not supported by Firefox 2, support has appeared in Firefox 3. It is also available in all current versions of IE, Opera and Safari.)
Editing using the keyboard and mouse works more or less as you would expect from a simple text editor. The cursor shows the entry point of the document and can be moved around the entire document. Set and delete work quite predictably. Selection can be moved, deleted and overwritten.
A very nice feature - by default, redo and undo (write and undo actions) work. (It will be described later on how to invoke the Undo command.)
Difficulties begin when the Enter / Return buttons are pressed. It is not entirely clear what kind of HTML code should be obtained as a result and, indeed, this code is very different in different browsers and depends on the context. If the cursor is inside a non-empty p tag, all browsers close it and open a new one (with the same attributes) and move the cursor to it. And Mozilla also inserts the (redundant) element br after the cursor. For example (in the examples, the vertical bar symbol indicates the cursor):
And pressing Enter / Return in IE or Safari:
If the cursor is at the end of a non-empty h1 element, all browsers close h1, but IE and Opera will insert a new p element and place the cursor in it. Safari inserts a new h1 element and places the cursor inside. Mozilla will not create any additional elements, but for some reason it will add two additional br tags after the cursor. For example:
After pressing Enter / Return in IE or Opera:
And in Mozilla:
And in Safari:
If you type text inside a div, Safari, Opera and IE close the current div element and open a new one. Mozilla inserts br and places the cursor after it.
If there are several wrapper elements around the cursor, then all browsers will close (and duplicate) only the wrapper with the highest degree of nesting. The cursor will remain wrapped.
Note: It's creepy! Unexpectedly, IE had the most sensible approach always guaranteeing sensible use of block elements. Mozilla behaves badly using the br elements inside block elements, so it’s impossible to implement meaningful text styling.
The cursor moves between characters. Not visible, as the cursor is positioned relative to the tags. The movement logic remains the same regardless of the browser. Regarding block elements: the cursor is always positioned inside the block element with the most nesting. For example, it is not possible to place the cursor between two paragraphs.
For example, look here; The vertical bar indicates the possible cursor positions:
If you delete a paragraph boundary, the result will be unchanged: the left block “wins” and the contents of the right block are included in the left block:
Safari, however, behaves intelligently (or terribly, depending on the point of view) and keeps the presentation of the right element unchanged:
Browsers support some additional editing interfaces.
IE allows you to resize images, tables, form elements or absolutely positioned elements by dragging their corners (when an object is selected, the corresponding container appears)
Mozilla also allows you to change the size of images and tables, but it also has additional controls that allow you to create new columns and rows in the table. In addition, Mozilla allows you to change the position of absolutely positioned elements.
The management interfaces for all this are absolutely proprietary, different in each browser and cannot be configured.
From the translator: Since Habr refused to publish 35kb text at a time, I split the translation into two parts.
WYSIWYG HTML editor in the browser. Part 2
The article discusses the basic principles and problems of unifying the features of editing in modern browsers. Topics covered in the article:
- Various methods to enable editing mode
- Editing commands
- HTML generated during editing
- DOM interaction
Introduction
In the very first browser created by Tim Bernes-Lee in 1990, web pages could be edited directly in the browser in WYSIWYG mode. The web was viewed as a readable and writable medium. Later browsers, however, basically allowed only readable information, except that text could be entered into form input fields.
WYSIWYG editing in the browser again became the norm with the release of Internet Explorer 5: the new designMode property allowed the user to edit the entire document. At first, this feature was somehow overlooked, possibly due to the fact that it appeared along with a host of other non-standard, proprietary capabilities of IE available only under Windows OS.
')
In recent years, other competing browsers — Mozilla, Safari, and Opera ( translator’s note: Chrome has not yet appeared at the time of this writing. The first beta will be released in just a few months. ) - they followed the example of IE and also implemented this feature. WHATWG is working on standardizing the editing mode - the designMode and contentEditable properties are presented in HTML 5. It seems that browser WYSIWYG editing is still becoming an integral part of the web.
The article discusses the basic principles and problems of unifying the features of editing in modern browsers. Topics covered in the article:
- Various methods to enable editing mode
- Editing commands
- HTML generated during editing
- DOM interaction
Note: I only consider editing features in browsers: Opera 9.5, Firefox 2+ and Safari 3, since in previous versions the editors were too buggy and incomplete. And the editor in IE has hardly changed since version 5.5)))
Edit Mode Overview
Edit mode makes the page or part of it editable. This is expressed in that:
- The cursor shows the current entry point. The user can enter text, delete it, etc. using the keyboard or mouse.
- Some browsers provide interfaces that allow you to change and move images, tables, and absolutely positioned elements.
- There are many built-in commands - Bold, Italic, InsertLink, Paste, Undo, and so on. (Bold, italic, paste a link, paste from the clipboard, undo an action, and so on.) These commands can be triggered by hot keys or using a script using the appropriate API.
- Using the Range and Selection API you can implement any changes to HTML. This can be used to implement non-standard commands.
- Edit mode allows you to modify HTML. And that's all. If you, for example, want to send it to the server in order to save the changes, then you will have to write the corresponding script.
- The commands and behavior of the editor are mostly not described by the specification and the resulting HTML code is very different in different browsers.
- The implementation in IE has hardly changed since the release of IE 5.5 (2000). The HTML code it generates can frighten sensitive people. If you think that you saw the last font tag in your life long ago, then a surprise awaits you! ( Translator's Note: Woo-and-and-and-and-and-and-and-and! )
Enable edit mode
There are two ways to enable editing mode - the designMode and contentEditable properties.
A window or frame becomes editable by setting the document's designMode property of the document to true. (Disclaimer: In IE, you need to get a link to the document from the window object.) Typically, an editable block is created using an IFrame and designMode.
Any element containing text can be made editable by setting the contentEditable property to true. (ContentEditable is not supported by Firefox 2, support has appeared in Firefox 3. It is also available in all current versions of IE, Opera and Safari.)
Keyboard Editing
Editing using the keyboard and mouse works more or less as you would expect from a simple text editor. The cursor shows the entry point of the document and can be moved around the entire document. Set and delete work quite predictably. Selection can be moved, deleted and overwritten.
A very nice feature - by default, redo and undo (write and undo actions) work. (It will be described later on how to invoke the Undo command.)
Difficulties begin when the Enter / Return buttons are pressed. It is not entirely clear what kind of HTML code should be obtained as a result and, indeed, this code is very different in different browsers and depends on the context. If the cursor is inside a non-empty p tag, all browsers close it and open a new one (with the same attributes) and move the cursor to it. And Mozilla also inserts the (redundant) element br after the cursor. For example (in the examples, the vertical bar symbol indicates the cursor):
- < p > bla bla | < / p >
And pressing Enter / Return in IE or Safari:
- < p > bla bla < / p >
- < p > | < / p >
If the cursor is at the end of a non-empty h1 element, all browsers close h1, but IE and Opera will insert a new p element and place the cursor in it. Safari inserts a new h1 element and places the cursor inside. Mozilla will not create any additional elements, but for some reason it will add two additional br tags after the cursor. For example:
- < h1 > bla bla | < / h1 >
After pressing Enter / Return in IE or Opera:
- < h1 > bla bla < / h1 >
- < p > | < / p >
And in Mozilla:
- < h1 > bla bla < / h1 >
- | <br> <br>
And in Safari:
If you write the text directly in the body (without any wrapper elements), and press Enter / Return, Mozilla inserts br. IE and Opera will wrap the previous text in p and create a new p. Safari will insert a div.
- < h1 > bla bla < / h1 >
- < h1 > | < / h1 >
If you type text inside a div, Safari, Opera and IE close the current div element and open a new one. Mozilla inserts br and places the cursor after it.
If there are several wrapper elements around the cursor, then all browsers will close (and duplicate) only the wrapper with the highest degree of nesting. The cursor will remain wrapped.
Note: It's creepy! Unexpectedly, IE had the most sensible approach always guaranteeing sensible use of block elements. Mozilla behaves badly using the br elements inside block elements, so it’s impossible to implement meaningful text styling.
Cursor positioning
The cursor moves between characters. Not visible, as the cursor is positioned relative to the tags. The movement logic remains the same regardless of the browser. Regarding block elements: the cursor is always positioned inside the block element with the most nesting. For example, it is not possible to place the cursor between two paragraphs.
For example, look here; The vertical bar indicates the possible cursor positions:
Regarding text elements, the cursor is positioned outside of all wrappers, if it is to the left of the text; if it is in the rightmost part, it is placed inside the wrappers. For example:
- < p > | P | 1 | < / p > < p > | P | 2 | < / p >
- < div > < p > | P | 3 | < / p > < div > < p > | P | 4 | < / p > < / div > < / div >
So if you type the characters to the left of bold text, the new text will be displayed in a normal style. If you type on the right, it will also be bold.
- < p > | A | < strong > < em > B | < / strong > < / em > C | < / p >
Deletion
If you delete a paragraph boundary, the result will be unchanged: the left block “wins” and the contents of the right block are included in the left block:
If you press Bk Sp, you will receive:
- < h1 > Overskrift < / h1 > < p > | Text < / p >
- < h1 > Overskrift | Text < / h1 >
Safari, however, behaves intelligently (or terribly, depending on the point of view) and keeps the presentation of the right element unchanged:
- < h1 > Overskrift | < span class = "Apple-style-span" style = "font-size: 16px; font-weight: normal;" > Text < / span > < / h1 >
Editing objects
Browsers support some additional editing interfaces.
IE allows you to resize images, tables, form elements or absolutely positioned elements by dragging their corners (when an object is selected, the corresponding container appears)
Mozilla also allows you to change the size of images and tables, but it also has additional controls that allow you to create new columns and rows in the table. In addition, Mozilla allows you to change the position of absolutely positioned elements.
The management interfaces for all this are absolutely proprietary, different in each browser and cannot be configured.
From the translator: Since Habr refused to publish 35kb text at a time, I split the translation into two parts.
WYSIWYG HTML editor in the browser. Part 2
Source: https://habr.com/ru/post/107829/
All Articles