question marks and parenthesis show up different places than typing in text edit Open TextEdit and open a standard content editable div, like http://www.mozilla.org/editor/midasdemo/ 1. Switch to Hebrew language input (International Settings) 2. mash the keyboard 3. hit ? 4. Notice that the ? is in a different place in TextEdit vs. a content editable div The div in midas demo LTR, so this is probably "correct" behavior. TextEdit is detecting that the user is typing hebrew and switching the context to RTL. It seems we should do something similar, no?
No, I don't think so. See bug 12337.
It seems at least that there are gmail users who want this "neutral" base writing direction functionality in gmail (like you mention in bug 12337). Which we could implement via JavaScript, but it would be better if the Browser handled it. I guess you're saying that this would require an extension to the CSS writing direction stuff to support this? Regardless of specs, I'm curious as to your preferred behavior, since at least 2 folks CC'd on this bug write RTL text much more often than I do. :)
So let me ask a naive question here: www.google.co.il automatically switches the base writing direction based on the first strongly directional character. I think that's a widely appreciated feature. Mitz: What parts of the web would be break if we built this functionality into WebKit? Are there any standards we'd be directly violating? Would we be increasing the usability of WebKit for users of RTL languages or breaking the web in some fundamental manner?
My take on this is that it would be nice to have that feature - as an option. That is, something like a new "auto" value for the dir attribute. I would not want it as a default because it would interfere with pages that already have auto-detection logic in script. It would also interfere with certain input types (e.g. paths, urls, source code) which should remain LTR even when they contain some (or even many) RTL chars. Certainly it must not be the default value for elements other than input and textarea, e.g. spans. This would be quite expensive in terms of CPU, and would break pages that happen to know that a particular string that has both LTR and RTL characters has overall LTR directionality, but do not indicate it because the page is LTR overall. The browser's auto-detection could incorrectly decide that the string is RTL and thus garble it. Also, the utility of auto-detection in inputs is quite limited when it is not backed up by site logic in processing the values provided by those inputs. In the www.google.co.il example, once the user clicks on the search button, the results page comes up - and displays the search string. It happens to display it correctly, even when its directionality is opposite to the page, because of server-side logic that auto-detected the directionality of the string and wrapped it in an appropriate <span dir=...>. Without that logic, the search string that looked ok in the input box due to the putative auto-detection logic built into the browser will be garbled in the results page. When we consider inputs that are not throw-aways like a search string, e.g. comments, it is clear that displaying the text correctly after it has been submitted is at least as important as while the user is entering it. However, an "auto" value for dir might come in handy for dealing with this too: the page could wrap the comment in a <div dir=auto>, without having to explicitly detect the directionality itself. All that is very nice, but I doubt very much that pages would start making use of dir=auto until support for it became widespread across the browsers. As long as one has to support one browser that does not support it, one probably wouldn't use it. If the dir=auto idea ever got implemented, it would be important to give access to the current calculated directionality to scripts that need to do some sort of more advanced logic. That would require a new method on the element object. Please note that I am talking about the dir attribute, and not so much about the CSS directionality property. According to the W3C, the right way to indicate the directionality of a string is with dir, not CSS, since it's a property of the string, and not a matter of style. Also please note that there is a number of algorithms for estimating the directionality of a mixed-script string, and there is always the possibility that the user meant it the other way. Thus, it is good to allow the user explicit control. In fact, in IE and FF there are keystrokes that do just that. Unfortunately, they do not coincide, and their semantics vary a bit, and the vast majority of users simply are not aware of them.