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