[Bug 16564] The directionality of a textarea should be determined based on its parent if its value does not have any strong characters

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16564

--- Comment #4 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> 2012-03-29 16:28:36 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > The reason for the current spec language is to keep the reordering results
> > consistent with plaintext. In plaintext, a paragraph of neutral characters is
> > ordered LTR.
> > 
> > I don't mind defaulting to the inherited direction when the element is empty,
> > if that makes for a better UI, but when it has neutral content, it should
> > default to LTR regardless of the inherited direction.
> 
> The HTML spec says LTR for any dir=auto element with all-neutral content, not
> just <textarea>. Ehsan, does this bother you for all elements, or specifically
> for <textarea>, because of the caret flip-flop problem?

Specifically for <textarea> because of the caret problem (well, I guess the
same argument can apply to unicode-bidi:plaintext elemnets which are editable,
but I won't get to that since those are not yet common on the web.)

> Please note that the behavior of <textarea dir=auto> is actually more in the
> province of CSS, since the HTML spec's default style sheet says that it gets
> unicode-bidi:plaintext, and that says that for each paragraph of the
> <textarea>, the base direction is determined by the first strong character in
> the paragraph, or LTR if none. The HTML directionality of the textarea is
> therefore largely moot.

That's actually not true, the UA might use the HTML directionality of the
textarea in order to customize its appearance.  For example, in Gecko we show a
resizer control for textareas by default, and we use the HTML directionality of
the element in order to determine where the resizer control should appear and
what it should look like.  Other UAs might provide their own customized
appearance for such textareas as well.

> In any case, I agree with fantasai. That is, the textarea in <div
> dir=rtl><textarea dir=auto>--></textarea></div> has to be displayed as "-->"
> (i.e. LTR), not <--, despite the parent being RTL. If, for a neutral value, it
> depended on the ancestor, then the display when entered will not necessarily
> match the way it is later displayed in a <pre> which happens to be displayed in
> a parent of the other directionality, e.g. in an opposite-directionality page.
> Also, LTR for all-neutral happens to work nicely for phone numbers (e.g. "(987)
> 654-3210"), which need to be displayed LTR.

I'm fine with that because I think that <textarea>'s appearance should match
that of unicode-bidi:plaintext paragraphs.

> As fantasai said, to avoid the caret flipping back to the left side after a
> newline and then again to the right when an RTL character has been entered, it
> is possible to change the CSS spec for the base direction of an *empty*
> paragraph in a unicode-bidi:plaintext element to follow the element's direction
> style. Alternatively, it could even follow the preceding paragraph's base
> direction. But that is a CSS matter. And please note that a non-empty,
> all-neutral paragraph (like "-->" or "2. ") will still be LTR (until the user
> adds on an RTL character). As I indicated above, I think that this is the way
> it should be.

Yes, I think we should change the behavior of textareas at least for the case
that they are empty.  If you think this should be done for all
unicode-bidi:plaintext elements (and fantasai agrees), we can move this to the
CSS spec.  That would be fine by me.  But that would not address the cases
where textarea directionality would matter, as I pointed out above.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 29 March 2012 16:28:44 UTC