- From: <bugzilla@jessica.w3.org>
- Date: Wed, 18 Jul 2012 06:58:53 +0000
- To: public-i18n-bidi@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835
Summary: The directionality of a textarea should be determined
based on its parent if its value does not have any
strong characters
Product: HTML WG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/mult
ipage/elements.html#the-dir-attribute
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: other Hixie drafts (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: contributor@whatwg.org
QAContact: contributor@whatwg.org
CC: fantasai.bugs@inkedblade.net, mike@w3.org,
public-i18n-bidi@w3.org, aharon.lists.lanin@gmail.com
This was was cloned from bug 16564 as part of operation convergence.
Originally filed: 2012-03-28 23:07:00 +0000
Original reporter: Ehsan Akhgari [:ehsan] <ehsan@mozilla.com>
================================================================================
#0 Ehsan Akhgari [:ehsan] 2012-03-28 23:07:35 +0000
--------------------------------------------------------------------------------
This is what the spec currently says:
If the element is a textarea element and the dir attribute is in the auto state
If the element's value contains a character of bidirectional character type
AL or R, and there is no character of bidirectional character type L anywhere
before it in the element's value, then the directionality of the element is
'rtl'. Otherwise, the directionality of the element is 'ltr'.
I think we need to revise this sentence: "Otherwise, the directionality of the
element is 'ltr'." Here's the problematic scenario:
Consider the following document:
<body dir="rtl">
<textarea dir="auto">RTL TEXT</textarea>
</body>
When you delete all of the characters inside the text area, according to the
spec the directionality gets switched to ltr, which causes the cursor to jump
back to left when the textarea is empty. If you start entering an RTL
character again, the cursor flips back to the right side. This is inconsistent
with the case where the default value of the textarea and the value you enter
are both LTR.
I don't remember why the spec was written in this way, but I need we need to
revise it to make the directionality depend on the direction of the parent
element if a dir=auto textarea has a value with no strong characters.
================================================================================
#1 fantasai 2012-03-29 00:24:40 +0000
--------------------------------------------------------------------------------
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.
================================================================================
#2 fantasai 2012-03-29 00:30:11 +0000
--------------------------------------------------------------------------------
Hmm, I guess you could have the HTML directionality of the element be RTL while
the base direction of the paragraph (as used for reordering) remains LTR... It
wouldn't be intuitive, but maybe it makes sense in some convoluted sort of way.
Was that what you were thinking?
================================================================================
#3 Aharon Lanin 2012-03-29 10:39:29 +0000
--------------------------------------------------------------------------------
(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?
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.
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.
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.
================================================================================
#4 Ehsan Akhgari [:ehsan] 2012-03-29 16:28:36 +0000
--------------------------------------------------------------------------------
(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.
================================================================================
#5 fantasai 2012-03-30 18:47:40 +0000
--------------------------------------------------------------------------------
So smontagu and I discussed this and we suggest adding to the definition of
'text-align: start/end' that
| In the case of an empty bidi paragraph, the direction used is that of the
| previous bidi paragraph, or, if this is the first bidi paragraph in the
| containing block, then the 'direction' property is used.
That should handle the caret.
================================================================================
#6 Ehsan Akhgari [:ehsan] 2012-03-30 18:56:44 +0000
--------------------------------------------------------------------------------
Right, but it won't handle other directionality specific UI effects that I
mentioned in comment 4.
================================================================================
#7 fantasai 2012-03-30 19:23:13 +0000
--------------------------------------------------------------------------------
I'm not convinced that what you're describing is the ideal behavior from a UI
perspective; imo the UI should be based on, if not the local of the browser, at
least the surrounding context of the UI element, not its content. So using
either the directionality of the browser chrome or using the directionality of
the input element's parent.
That said, I have no problem with HTML defining empty dir=auto elements (that
contain not even white space) to resolve to the directionality of their parent.
================================================================================
#8 Aharon Lanin 2012-04-01 20:46:54 +0000
--------------------------------------------------------------------------------
IMO, the way to optimize the UX of resizing a textarea is to always put the
resize control on the side of the textarea that will actually move if the
textarea's width is changed. And I admit that putting the resizer in the
textarea's end side does not always achieve it. However, neither does putting
it on the end side relative to the textarea's parent, or on the end side
relative to the browser's locale. Here are three examples that show that which
side of the textarea moves when the textarea's width is changed is not
necessarily affected by the direction (and sometimes even the alignment) of
*anything*:
data:text/html,<div style="text-align:right"><textarea></textarea> *** </div>
data:text/html,<div style="text-align:right"><div style="display:inline-block;
text-align:left"><textarea></textarea> *** </div></div>
data:text/html,<div style="float:right"><textarea></textarea> *** </div>
In any case, my bottom line is the same as fantasai's: do not set an empty
<textarea dir=auto>'s direction to be the same as the parent element. It does
not necessarily improve the UX of resizing it.
================================================================================
--
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 Wednesday, 18 July 2012 06:58:55 UTC