[Webkit-unassigned] [Bug 25747] question marks and parenthesis show up different places than typing in text edit

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 14 00:29:28 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=25747


aharon at google.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aharon at google.com




------- Comment #4 from aharon at google.com  2009-05-14 00:29 PDT -------
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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list