You are not logged in.
Pages: 1
FastMail.FM is currently testing Xinha alongside FCKeditor on their beta server as possible replacements for HTMLarea 3 that is currently used by FastMail.FM for composing HTML email in the webmail interface. See here.
FastMail.FM is an IMAP/webmail provider with several hundred thousand registered users. It might be interesting to xinha developers to see how xinha fits in an email system (that has quite different requirements than more "traditional" uses of an online composer such as online forums or website editting. Email is a very demanding environment in some respects).
Offline
Interesting, looks like Xinha might be winning against FCK over there. The RTL problem hasn't been reported before that I am aware of, looking at the code it's obvious that it would be a problem (because the rtl/ltr button only changes the direction of the parent block element). I don't know if EnterParagraphs (or IE) would maintain that directionality in new paragraphs created by hitting enter in the changed one, I doubt it.
James Sleeman
Offline
In a way Xinha has already won in the past. HTMLarea 3 was prefered to FCKeditor. Xinha is much closer to the HTMLarea 3 that is the current editor on FastMail's compose screen so this is a clear advantage.
The RTL problem is not a big problem in an environment where you are working on getting a webpage to look just right. It becomes a "big" problem in an environment where you just want to get your work done and don't want to be bothered by making sure it looks right.
Offline
I think it's just more the fact that we don't have any developers who use RTL languages so we're not at all familiar with how these things are normally done :-)
If there are any developers out there who use some rtl language on a computer please chime in, even better if you know Javascript :-)
James Sleeman
Offline
I am not a developer, only a FastMail user, and consequently a heavy user of HTMLarea 3, and hopefully in the future of Xinha. Also I am a speaker of two starnge languages, Hebrew and math, and have to communicate by email with students using a mix of the two, and the mixture should be quite perfect since I cannot expect the poor students to be able to cope with bad presentation. Coping with the math itself is enough work for them. SO doing it with HTML email you can see that I pretty much have to stretch the capabilities of HTML. And I also like to find out how things work, so I often read the source of webpages and scripts to understand how they work, and I did this with the source of HTMLarea 2, which was pretty easy to read, but not with HTMLarea 3 which was more complicated. Anyway it was enough to understand how things work in principle, and enough to guide one of my students that analyzed the proprietary js HTML composer used in the university forums and find additional functionality that was not available in the interface but could be used in bookmarklets.
The RTL/LTR issue is not that complicated (unless you want to understand the Unicode bi-di algorithm). They are just attributes that can be applied to certain tags, and can be overidden by more internal tags.
There are two possible text directions of course (LTR/RTL) and LTR is the default. They can be used in tags like <body>, <p>, <div>, <span> and probably some others I haven't thought about. In addition they are used in <table>s (or perhaps in <tr>s? I don't use tables often) to tell in what direction to order the cells in a row. And in addition there is one additinal <bdo> tag ("bi-di overide")in HTML 4 that can be used with either dir-ltr or dir=rtl that has a different effect: it overides the directionality algorithm and lays out all the text in the specified direction. So if you do something like <bdo dir=rtl>English</bdo> the HTML would be rendered as "hsilgnE" (if it were <span dir=rtl>English</span> it would be rendered as "English" since the sequence of latin letters determine its internal directionality).
Anyway, forthe purpose of implementing these you don't have to understand how the directionality is treated by the HTML redering engine. Just that it's an attribute that applies to everything between a pair of tags, unless there is an internal pair of tags that overides it.
Another little complication of directionality is its relationship with alignment. If you're unaware of directinality then you know that left alignment is the default. However, the HTML specification says that this is so where the directinality is LTR (this includes unspecified directionality - the default is LTR). If the directionality is RTL then the default alignment becomes right (this affects only the case of RTL and unspecified alignment). When a user applies RTL directionlity to a paragraph (or more than a paragrph) then it may be assumed that right alignment is also requested (even if it occurs within a range where align=left or align=center was explicitly specified. Of course if after the directinality is applied the user asks for any alignment then that alignment should be applied then). When text is selected and is not a whle paragraph then I guess there is no meaning to alignment, and the most suitable treatment is to surrond it with a <span> range with the directionality the user wanted (or add the directionality attribute to existing span tag if it is an exact match).
Directionality is specified either by dir=ltr or dir=rtl attributed (which the W3C probably call "depracated" except in <bdo> tags) or by CSS (style="direction:rtl" which is probably the W3C prefered way).
I think this covers most of it. Implementation should not be something much different from applying other tags to text (such as font specification, colors, styles etc.).
he issues mentioned in the FastMail forum about implementaion of directionality were two: one is that when the user composes and presses "Enter" to start a new paragraph, the user expects that the formating applied to the new paragraph would be the same as the previous one, unless explicitly changed by the user. It was mentioned with respect to directionality, but I think this is a general expectation that applies to all formatting options. The other issue was that the state of the buttons in the interface should reflect the formating that would be used in the current position of the cursor. So here's a dillema: if no alignment is specified, then left alignment is applied by default. Should the interface show no alignment button pressed (no alignment specified) or the left alignment button pressed (left alignment applied here). Both are legitimate. With the directionality buttons it looks a bit more complicated but itis the same issue: if RTL is specified and no alignment specified, should the buttons reflet this (RTL pressed, no alignment button pressed) or reflect the way text must be rendered (RTL button pressed, and right align button pressed because text here must be right aligned by default if no alignment is specified). There is almost no difference between the two options, since the defaults are hard-coded into the HTML specification. There is a slight difference in that bi-di enabled brosers (bidi IE and FF with bidi plugin) allow the user to change the directionality. What this does is overide the directionality specified for the <body> tag. So if ltr directionality is explicitly stated for an internal element (such as a <p> tag) the user would not be able to overide it, but if it is implied by default, the it would inherit the rtl directionality form the <body> if the user tells the browser to use rtl on the web page. Theoretically I think the interface should reflect the internal structure of the document. But in an email environment people don't have time to think about the different possible renderings of HTML due to different viewers' behaviour. Just to get the work done fast and getting the expected result without having to think too much about form.
Offline
Pages: 1