- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Nov 2010 09:21:55 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10809 --- 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. True. > 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 different. 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