[Bug 10809] i18n comment 3 : new attribute: submitdir

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10809

Aharon Lanin <aharon.lists.lanin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|NEEDSINFO                   |

--- Comment #21 from Aharon Lanin <aharon.lists.lanin@gmail.com> 2010-10-18 14:15:52 UTC ---
(In reply to comment #19)
> Hm, yes, usernames are a good example of something where this wouldn't work.
> 
> This definitely argues for an opt-in solution. However, it's still not clear to
> me that having multiple submission fields is a good idea. If the user has
> opted-in to getting this information, is there any harm at that point in
> "simply" making the submitted data have appropriate bidi formatting characters?

Yes, there is.

1. The app needs the direction metadata as a separate piece of information. For
example, when displaying the data, the direction needs to be indicated via the
dir attribute, not formatting characters, in order to comply with existing W3C
recommendations that highly discourage the appearance of formatting characters
in HTML (except for contexts that do not allow mark-up, e.g. inside the title
element). Thus, the app will have to strip away the formatting characters added
by the user agent because of submitdir (and store the direction metadata
separately). Or, to continue with the example of this site's user names, let's
say that the site had submitdir on the username input in the page for defining
a new account, so that the user can indicate (in the usual manner) the correct
way to display his or her username. The app will then have to strip off the
formatting characters because the user should not have to enter the username
with the formatting characters every time he or she logs in.

The very need of having to extract metadata from the data - and then to strip
the metadata out of the data - makes the suggested approach clumsy.

2. Detecting and stripping away the formatting characters would be more
difficult than one might think. The correct way to indicate direction in
formatting characters is to wrap the data in an LRE or RLE at the beginning and
a PDF character at the end. However, it is not good enough to simply check
whether the first character is LRE or RLE and the last character is PDF, since
that would misunderstand (and garble) the string "[LRE]css[PDF] IS MORE FUN
THAN [LRE]html[PDF]".

3. There is no way to tell whether the formatting characters were added by the
user agent as metadata or entered by the user to be a permanent part of the
data. To continue with the example of this site's user names, if it was the
user that entered the formatting characters into the username for some strange
reason, and intends to enter them at every log-in, stripping them off is not
good.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 18 October 2010 14:15:55 UTC