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

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 the QA contact for the bug.

Received on Thursday, 4 November 2010 07:04:05 UTC