Brion Vibber wrote:
William Allen Simpson wrote:
We covered these issues in great detail in the
IETF over a decade ago.
There was a lot of acrimonious argument then, too, but Hank (and others)
did a great job drafting a technical solution that solved the
transmission and editing problems.
(1) A canonical form for storage and transmission. In SMTP, all storage
and transmission is LTR. I don't see why that couldn't apply here, too.
Sure, it makes Hebrew appear backward in storage, but we usually don't
look at the stored version.
(2) Display and edit as RTL. In practice, this turned out to be fairly
simple by thinking about such things as opening and closing parentheses,
rather than left and right. They simply are reversed on display.
(3) This allows all email to be parsed consistently, without change to
the existing mail transmission programs, while specialized mail user
agents (MUA) handle display of the text body.
Well, we work in a Unicode/XML/HTML context, and for better or for worse the W3C
world has explicitly embraced bidirectional text stored in logical order.
Yes, that's good, a canonical form for storage.
Parsing of markup happens on text in logical order.
Since the markup is very
much embedded in the text and requires both exposure to human editors and
consistent parsing by the machine, I'm not sure that e-mail is a good
comparison. The 'markup' in e-mail is invisible to the user: headers, escape
codes, MIME content part separators.
But not when editing. The edits are handled by specific MUA. Some expose
the raw markup, others hide the markup and handle the conversions.
Our output is to HTML, and editing is done in a web
browser. This is a heavily
bidi-centric environment which I don't think we could really override if we
wanted to.
I'm sorry, perhaps I'm not sufficiently clear. The final output of text
pages should always be handled in the standard canonical manner.
It's the edits that seem to be the problem. The edit box is defined and
filled and processed by Wiki software. That is, this software is providing
the UI. So, I was proposing that the Wiki software do the flipping into
the edit box, then reversing and preprocessing from the edit box back into
the canonical format.
That is, folks seem to have a problem with treating the edit box the same as
a raw text editor. I was using the parallel that user freindly email
editors don't treat the text as "raw", instead they handle the user edit
processing and conversion from/to the canonical format.
Likewise, the difference in editing pages with Mozilla as opposed to the
raw HTML with BareBone's BBEdit (my personal preference). Most folks seem
to like the former.
Still clear as mud?