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)
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