The current code of the Visual Editor reimplements many basic editing functions, which are available in the browsers: text selection, alignment, cursor movement and appearance and even cursor blinking.
This is a major problem for internationalization. These functions work very differently in different languages. Most browsers already support most of the needed functionality in textarea and in content-editable. Overriding them in the Visual Editor means that it will be unusable in any language except English.
To name just a few basic examples:
* Cursor shape: In bidirectional environments the cursor has an arrow pointing in the writing direction. In the current VE it's just a stick. See https://en.wikipedia.org/wiki/Text_cursor#Bi-directional_text
* Cursor position: VE always positions the cursor as it the text is left-to-right. The same goes for text selection.
* Word boundary: Ctrl-left/right arrow moves the cursor word by word. Browsers support all Unicode scripts for word boundary identification, but in the current VE it only works with ASCII.
* Character segmentation and cursor movement: A letter with one or more diacritics is one character segment according to Unicode (UAX #29), even if internally it's composed of several Unicode characters. For example, <שָּׁ> is composed of four characters, but only one arrow key press is supposed to move the cursor over it. That's what the browsers already do for years, but in the Visual Editor, four key presses are needed.
This is just a small sample of the potential issues.
Bugs are already reported for some of these issues, but the basic question is - why reimplement it all in the first place? Why not use what the browsers offer as much as possible?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Amir,
Bugs are already reported for some of these issues, but the basic question is - why reimplement it all in the first place? Why not use what the browsers offer as much as possible?
there is actually a possibility that a very atypical way to use contenteditable might make a cameo appearance as a thin surface layer to help with input stuff (see VisualEditor/contentEditable for a prototype). The atypical bit mostly stems from the need to avoid the many problems current contenteditable implementations have, and the desire to support a good user experience while editing *wiki* content. In any case, the editor team is currently hard at work on exactly these problems, as is described in https://www.mediawiki.org/wiki/Visual_editor/Phase_2.
https://www.mediawiki.org/wiki/Visual_editor/Bidirectional_text_requirements and Visual editor/Internationalization requirements are helping a lot in this work, thank you for documenting these things!
Gabriel
(who knows very little about the horrors of contenteditable implementations..)
VisualEditor project consists of at least those parts:
* parser (current implementation in JavaScript on NodeJS) * WikiDOM/HTMLDOM * EditingSurface (JavaScript)
Recently we discussed the possibility of developing alternative to EditingSurface based on ContentEditable. I'm already working on it with Christian Williams from Wikia and you can see some code here: https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/VisualEditor/con.... Soon (probably later this week) we will know if we are going to spend more time on it.
Idea here is not to replace EditingSurface (at least not yet) but to figure out how good and reliable ContentEditable is for our needs.
(We are going to use ContentEditable for "text interactions" and WikiDOM/HTMLDOM transaction processor for things like: adding/deleting/spliting/merging nodes).
Inez
On Sat, Jan 28, 2012 at 3:47 AM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
The current code of the Visual Editor reimplements many basic editing functions, which are available in the browsers: text selection, alignment, cursor movement and appearance and even cursor blinking.
This is a major problem for internationalization. These functions work very differently in different languages. Most browsers already support most of the needed functionality in textarea and in content-editable. Overriding them in the Visual Editor means that it will be unusable in any language except English.
To name just a few basic examples:
- Cursor shape: In bidirectional environments the cursor has an arrow
pointing in the writing direction. In the current VE it's just a stick. See https://en.wikipedia.org/wiki/Text_cursor#Bi-directional_text
- Cursor position: VE always positions the cursor as it the text is
left-to-right. The same goes for text selection.
- Word boundary: Ctrl-left/right arrow moves the cursor word by word.
Browsers support all Unicode scripts for word boundary identification, but in the current VE it only works with ASCII.
- Character segmentation and cursor movement: A letter with one or
more diacritics is one character segment according to Unicode (UAX #29), even if internally it's composed of several Unicode characters. For example, <שָּׁ> is composed of four characters, but only one arrow key press is supposed to move the cursor over it. That's what the browsers already do for years, but in the Visual Editor, four key presses are needed.
This is just a small sample of the potential issues.
Bugs are already reported for some of these issues, but the basic question is - why reimplement it all in the first place? Why not use what the browsers offer as much as possible?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
I will just add that not all browsers handled bidi the same, but the current approach of VisualEditor could fix that. Since we are doing everything from scratch, we can implement the "correct" way, and it will work everywhere.
Also, unlike ContentEditable (which as Inez says we aren't totally writing off still) the VisualEditor's edit surface approach allows us to easily handle things like the way the cursor looks based on where it's placed. Remember, yes we have to implement it (which can be a pain) but we can implement just about anything, and it will be much more consistent across browsers.
Another issue we are looking at is IME - which is badly broken in both the edit surface and content editable approaches still. This is a really big problem for i18n as well, and we are now taking the time to make sure it's done right. Not only are we aiming to support OS powered IME where possible, but we will also be integrating Narayam. It's also important to recognize that many browsers don't support IME correctly either, so again we have an opportunity to make a correct implementation that works the same everywhere.
In short, these challenges are not entirely unique to us, and we have an opportunity to do even better than other's have done.
- Trevor
On Mon, Jan 30, 2012 at 3:30 PM, Inez Korczynski inez@wikia-inc.com wrote:
VisualEditor project consists of at least those parts:
- parser (current implementation in JavaScript on NodeJS)
- WikiDOM/HTMLDOM
- EditingSurface (JavaScript)
Recently we discussed the possibility of developing alternative to EditingSurface based on ContentEditable. I'm already working on it with Christian Williams from Wikia and you can see some code here: https://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/VisualEditor/con.... Soon (probably later this week) we will know if we are going to spend more time on it.
Idea here is not to replace EditingSurface (at least not yet) but to figure out how good and reliable ContentEditable is for our needs.
(We are going to use ContentEditable for "text interactions" and WikiDOM/HTMLDOM transaction processor for things like: adding/deleting/spliting/merging nodes).
Inez
On Sat, Jan 28, 2012 at 3:47 AM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
The current code of the Visual Editor reimplements many basic editing functions, which are available in the browsers: text selection, alignment, cursor movement and appearance and even cursor blinking.
This is a major problem for internationalization. These functions work very differently in different languages. Most browsers already support most of the needed functionality in textarea and in content-editable. Overriding them in the Visual Editor means that it will be unusable in any language except English.
To name just a few basic examples:
- Cursor shape: In bidirectional environments the cursor has an arrow
pointing in the writing direction. In the current VE it's just a stick. See https://en.wikipedia.org/wiki/Text_cursor#Bi-directional_text
- Cursor position: VE always positions the cursor as it the text is
left-to-right. The same goes for text selection.
- Word boundary: Ctrl-left/right arrow moves the cursor word by word.
Browsers support all Unicode scripts for word boundary identification, but in the current VE it only works with ASCII.
- Character segmentation and cursor movement: A letter with one or
more diacritics is one character segment according to Unicode (UAX #29), even if internally it's composed of several Unicode characters. For example, <שָּׁ> is composed of four characters, but only one arrow key press is supposed to move the cursor over it. That's what the browsers already do for years, but in the Visual Editor, four key presses are needed.
This is just a small sample of the potential issues.
Bugs are already reported for some of these issues, but the basic question is - why reimplement it all in the first place? Why not use what the browsers offer as much as possible?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Wikitext-l mailing list Wikitext-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l
wikitext-l@lists.wikimedia.org