- From: <bugzilla@jessica.w3.org>
- Date: Thu, 04 Nov 2010 07:04:03 +0000
- To: public-i18n-bidi@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10809 --- Comment #38 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-11-04 07:04:01 UTC --- (In reply to comment #31) > 1. It is very easy for these characters (where the PDF is the "closing > parenthesis" to the others) to get out of balance and become completely > nonsensical, e.g. [PDF][LRE]. Of course, the same can be said for HTML's > opening and closing tags, but if the tags are out of balance, the document is > invalid, and your authoring tools will help you prevent that from happening. > The formatting characters, being just text, do not affect the validity of the > document, and you are completely on your own. We should definitely make them affect the validity if it's a concern that people will use them incorrectly and could benefit from validator tools flagging these problems. Please file a bug suggesting this if you think it would help. > 2. Similarly, these characters, while being perfectly balanced on their own, > can very, very easily become "entangled" between the scopes of the document's > tags. For example, what exactly is the browser to make of <span dir=rtl> ... > [LRE] ... </span> ... [PDF]? What should happen is defined by CSS, which defines all of the bidi formatting rules in terms of bidi formatting characters. > 3. Speaking of CSS, how exactly should the formatting characters - if > encouraged - interact with the direction-dependent CSS, e.g. text-align:start? > For example, consider: > > [RLE]<div style="text-align:start">blah blah</div>[PDF] > > Should the direction CSS property be rtl for the div? Should it be aligned to > the right? What if the [RLE] and [PDF] were inside the div? The meaning of 'start' is entirely based on the 'direction' property and nothing else. This is all defined in the CSS spec. > However, the fact remains that in many cases, > opposite-direction text gathered from the user is best displayed aligned to its > start edge. So, to get that, I will still need to make the *div* say dir=rtl, > and not leave it up to the text inside the div. Why not just use dir=auto? If the first character is a bidi formatting character, that'll work as intended, no? > And in order to do that after > the browser has stuck the formatting characters into text (because the user > entering it indicated its direction), the server side of my app will need to > parse the text in order to figure out that indeed it is wrapped in formatting > characters. And when I say "parse", I really mean parse: while the formatting > characters in "[RLE]BLAH blah BLAH[PDF]" might (!) have been inserted by the > mechanism you are proposing, the formatting characters in "[RLE]BLAH[PDF] blah > [RLE]BLAH[PDF]" definitely were not, and to understand that, the app will need > to scan right through the whole string. How would a user ever end up submitting text in this latter state? Why would you not use dir=rtl in this case anyway? > As I said, I have no intention of using submitdir to support the use case of > the user indicating the direction of individual paragraphs inside a textarea > (as opposed to indicating the direction of all the paragraphs in a textarea at > once). That seems a bit limited, but if it's really not something people want to do, fair enough. Anyway, I can see the appeal (in terms of simplicity) of out-of-band direction indication. I'll look into the feasability of just having a boolean attribute on <input> and <textarea> that results in a separate field in the submission. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. You reported the bug.
Received on Thursday, 4 November 2010 07:04:05 UTC