W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2010

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 10 Nov 2010 09:21:55 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PG6sN-00026l-EA@jessica.w3.org>

--- Comment #46 from Aharon Lanin <aharon.lists.lanin@gmail.com> 2010-11-10 09:21:54 UTC ---
(In reply to comment #44)
> (In reply to comment #43)
> > 3. If you do want to specify a complete name, there is also a completely
> > different alternative: pull instead of push. We could have an attribute named
> > dirof, or even directionof, and its value would be the name of another control [...]
> > The default stylesheet would make all inputs with directionof hidden by
> > default.
> I like this proposal.  Except that 1. it's a lot of typing.

Agreed, but that does not particularly bother.

>  2. To work best
> with older browsers, you need to manually hide it anyway, so, no gain there.


> Here's yet another proposal:
> <input name=foo type=text xxx=xxx>
> where xxx is whatever attribute name we comeup with.  What this does though, is
> that it will instruct the agent to included exactly one of U+200E or U+200F at
> the beginning of the submitted text, depending on the resolved direction of the
> text.

The characters being proposed here are LRM and RLM. The discussion above had
dealt with LRE and RLE (and a PDF at the end), which are both similar and

One difference is that there is no objection to the use of LRM and RLM in HTML,
so in this sense this proposal is better than wrapping in LRE|RLE and PDF.

Another difference, however, is that although the first-strong estimation
algorithm would in fact estimate a string starting LRM|RLM to be in the
intended direction, LRM and RLM do not declare direction. They are just
invisible strong-directional characters, like an invisible A and an invisible
alef. They do not guarantee that the remainder of the string is displayed in
the intended direction, and in fact their normal use case is for strictly local
effect (e.g. "[LRM]10 main street IS THE ADDRESS.", which is intended to be RTL
overall - the leading LRM just makes the LTR address get displayed as intended,
instead of as "main street 10").

Thus, when displaying a string obtained using the proposed feature in another
HTML page, the application would either have to wrap it in an element with
dir=auto, or check for the leading character, optionally remove it, and wrap
the string in an element with dir=ltr|rtl. When displaying the string in plain
text, where dir=auto is not an option, the application would have no choice but
to check for the leading character, optionally remove it, and wrap the string
in LRE|RLE and PDF. The advantage of using LRE|RLE and PDF - that you can just
leave the formatting characters in place and get the intended display wherever
you happen to plop the string - is gone. In this sense, this proposal is even
worse than wrapping in LRE|RLE and PDF.

And, in fact, removing the LRM|RLM before including the string in output is
pretty much essential. If it is not removed, and the user copy/pastes it along
with the string, it will eventually cause problems: editing a string containing
invisible characters is always fun, ands the effects of the LRM|RLM when the
string is reused are unpredictable, since, as already noted above, LRM|RLM does
not declare the direction of anything. And if it is not removed before being
used as the default value of an input in another page, the added formatting
characters would build up ad infinitum.

Furthermore, please note that it is impossible, given a string of unknown
provenance, to tell whether its leading LRM|RLM was put there by the proposed
feature or put there by the string's author for a purpose very different than
indicating the string's overall direction. Thus, the proposed feature would
have to *always* add the LRM|RLM to the string reported in the submission, so
the application knows that whatever it gets always has a leading LRM|RLM that
indicates the overall direction.

Given that the application would then proceed to strip the LRM|RLM for the
reasons indicated above, I propose that adding a leading LRM|RLM is roughly the
same as adding any other prefix to the string, even a visible one like either
"ltr" or "rtl". On the other hand, and is much easier to abuse than an
out-of-band method like another form control, as originally proposed.

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 Wednesday, 10 November 2010 09:21:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC