Bug 17835 - The directionality of a textarea should be determined based on its parent if its value does not have any strong characters
The directionality of a textarea should be determined based on its parent if ...
Status: RESOLVED FIXED
Product: WHATWG
Classification: Unclassified
Component: HTML
unspecified
Other other
: P3 normal
: Unsorted
Assigned To: Ian 'Hixie' Hickson
contributor
http://www.whatwg.org/specs/web-apps/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 06:58 UTC by contributor
Modified: 2013-07-03 22:39 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-07-18 06:58:53 UTC
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.
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-09-26 22:45:58 UTC
So what's the story here? Should the HTML spec change or not?
Comment 2 Aharon Lanin 2012-09-27 11:24:29 UTC
(In reply to comment #1)
> So what's the story here? Should the HTML spec change or not?

IMO, it should not. I do not speak for fantasai or Ehsan.
Comment 3 Ehsan Akhgari [:ehsan] 2012-09-27 13:35:12 UTC
I would be fine with us proceeding with bug 16564 comment 5, which would be a CSS change.  fantasai: do you agree?
Comment 4 Aharon Lanin 2012-09-27 15:43:37 UTC
(In reply to comment #3)
> I would be fine with us proceeding with bug 16564 comment 5, which would be a
> CSS change.  fantasai: do you agree?

It is already in the Text level 3 spec (see last sentence of the quote below):

The start and end edges of a line box are determined by the inline base direction of the line box. In most cases, this is given by its containing block's computed ‘direction’. However if its containing block has ‘unicode-bidi: plaintext’ [CSS3-WRITING-MODES], the inline base direction the line box must be determined by the base direction of the bidi paragraph to which it belongs: that is, the bidi paragraph for which the line box holds content. An empty line box (i.e. one that contains no atomic inlines or characters other than the line-breaking character, if any), takes its inline base direction from the preceding line box (if any), or, if this is the first line box in the containing block, then from the ‘direction’ property of the containing block.
Comment 5 Ian 'Hixie' Hickson 2012-12-29 07:45:14 UTC
The directionality of <textarea> basically determines only the directionality sent in form submission (if dirname="" is given) and the directionality of the title="" tooltip and placeholder="" message.

I'm fine with defaulting to inherited if the element is strictly empty, but then shouldn't we also do that for regular elements with dir=auto?
Comment 6 Aharon Lanin 2013-02-19 08:09:23 UTC
(In reply to comment #5)
> The directionality of <textarea> basically determines only the
> directionality sent in form submission (if dirname="" is given) and the
> directionality of the title="" tooltip and placeholder="" message.

It also determines the direction style, and through that affects things like the side on which the caret appears in an empty <textarea> (as specified for unicode-bidi:plaintext), as well as the side on which its scrollbar and its resizing control appear (even though those are not part of any spec). It is those effects that prompted this bug to be filed.

> I'm fine with defaulting to inherited if the element is strictly empty, but
> then shouldn't we also do that for regular elements with dir=auto?

In my current opinion (this differs from what I expressed earlier), defaulting the directionality of a textarea or input with dir=auto to be inherited when its value is empty will usually result in a better user experience when the element appears in an RTL context:
- The caret would appear on the right, which is better (i.e. does not result in a caret jump) when the user enters RTL text, which is presumably the more common case in an RTL page.
- Although this is not governed by any spec, in all current browsers the scrollbar would appear on the left. This, once again, is better (scrollbar does not jump) in the more common case that the user enters RTL text.
- The resize control would appear on the left, which usually (but not always, see comment #8) makes it work better (but this is browser-dependent and not governed by any spec).

The same probably applies to a contentEditable element with dir=auto.

For dir=auto elements that do not allow user input (i.e. neither contentEditable nor <textarea> nor <input>), inheriting directionality when the content to which the first-strong algorithm is to be applied is empty also seems to be somewhat better. The use case there would be something like the chat example at the bottom of http://www.w3.org/html/wg/drafts/html/master/dom.html#the-dir-attribute. When a chat entry is empty, it would be best to display the chatter's name on the start side relative to the page. It's not a biggie by any means, but it's a "pro".
Comment 7 Ian 'Hixie' Hickson 2013-04-10 23:27:43 UTC
Ok, I tried to make dir=auto defer to the parent in some cases.
Comment 8 contributor 2013-04-10 23:28:19 UTC
Checked in as WHATWG revision r7805.
Check-in comment: Make dir=auto inherit when the element has no obvious directionality. (Except for <bdi>, which still defaults to ltr.)
http://html5.org/tools/web-apps-tracker?from=7804&to=7805
Comment 9 Ian 'Hixie' Hickson 2013-04-10 23:29:37 UTC
Woops, I accidentally included a bunch of editorial changes I had batched up and not yet committed. Sorry about that. The bidi fix is the two blocks starting at:
  @@ -9723,9 +9670,20 @@

Ignore everything else.
Comment 10 Aharon Lanin 2013-04-11 06:35:36 UTC
No good. As it reads now, it applies the inherited directionality to dir=auto elements whose content is *neutral*. What was being discussed was to apply it only to ones whose content is *empty*. Non-empty neutral content should be LTR regardless of the parent as before.
Comment 11 Ian 'Hixie' Hickson 2013-04-15 22:39:18 UTC
Why would <textarea></textarea> want to inherit but <textarea> </textarea> not?

I don't follow. Why would you want the neutrals to always be ltr?
Comment 12 Aharon Lanin 2013-04-17 06:59:38 UTC
(In reply to comment #11)
> I don't follow. Why would you want the neutrals to always be ltr?

See comments 1 and 3 from the original bug, i.e.:

 #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.
================================================================================
 #3   Aharon Lanin                                    2012-03-29 10:39:29 +0000 
--------------------------------------------------------------------------------
[...]

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.
Comment 13 Ian 'Hixie' Hickson 2013-04-25 03:35:35 UTC
Ah, ok. That makes some sense.
Comment 14 Ian 'Hixie' Hickson 2013-04-25 03:39:13 UTC
But I'm not sure it makes 100% sense.

Consider this:

   <body dir=rtl><textarea dir=auto></textarea>

If you focus the control, and press the space bar, surely you're not saying the cursor should jump from the right hand side to the left hand side? And then if you press a single Arabic character it should jump back to the right hand side?

I agree that <textarea dir=auto> and <pre dir=auto> should render the same, but why does it therefore follow that <textarea dir=auto>--></textarea> should render as a right-pointing arrow rather than a left-pointing arrow?
Comment 15 Aharon Lanin 2013-04-30 12:16:38 UTC
(In reply to comment #14)
> But I'm not sure it makes 100% sense.

I don't claim it does. Nor do I claim that the first-strong algorithm is the best there could be. But it has the advantage of simplicity and - more importantly - it is the only recognized standard (via Unicode). And thus it is the only reasonable way to get a high percentage of cases where a reasonable behavior results.

> Consider this:
> 
>    <body dir=rtl><textarea dir=auto></textarea>
> 
> If you focus the control, and press the space bar, surely you're not saying
> the cursor should jump from the right hand side to the left hand side? And
> then if you press a single Arabic character it should jump back to the right
> hand side?

I am, on both counts. I am not saying it is a case where it gives a good result. But it is not a very common case. A better illustration for your argument would be when one enters something like "1. " followed by an RTL character - a common case indeed.

The counterbalance is cases like "(987) 654-3210" and "+19876543210" which are simply incorrect when displayed RTL. Not inconvenient - incorrect. Telephone numbers are important.

> I agree that <textarea dir=auto> and <pre dir=auto> should render the same,
> but why does it therefore follow that <textarea dir=auto>--></textarea>
> should render as a right-pointing arrow rather than a left-pointing arrow?

Because <pre dir=auto> should also be used to display plain text obtained from external sources (not just entered via <textarea dir=auto>), and the only reasonable assumption to make for such text is that it was written to come out as intended under default Unicode rules. (Yes, I know that not all plain text editors follow those rules, but it is the only standard we have. It's not like the other editors follow some reasonable, consistent alternative.) And directionality can matter even for all-neutral, non-numeric text. For example, if the text is something like:

--- start of example ---
:-)

That's a good one.
--- end of example ---

then you don't want it coming out like:

--- start of example ---
                                   (-:

That's a good one.
--- end of example ---
Comment 16 Ian 'Hixie' Hickson 2013-04-30 18:13:31 UTC
Ok. Well, first, type=tel dir=auto can be rtl always. (Maybe it should even be rtl if dir="" is omitted entirely?)

I've made <textarea dir=auto> default to RTL if it contains RTL characters, parent if empty, LTR otherwise.

How about other elements? What direction should this be in?

   <div dir=rtl>
     <div dir=auto>1.</div>
     RTLRTLRTL...
   </div>

...?
Comment 17 contributor 2013-04-30 18:14:51 UTC
Checked in as WHATWG revision r7863.
Check-in comment: Work on dir=auto. More work may come.
http://html5.org/tools/web-apps-tracker?from=7862&to=7863
Comment 18 Aharon Lanin 2013-05-21 08:51:25 UTC
(In reply to comment #16)
> Ok. Well, first, type=tel dir=auto can be rtl always. (Maybe it should even
> be rtl if dir="" is omitted entirely?)

I presume you meant ltr, not rtl. Telephone numbers need to be displayed LTR.

While I do think it would be neat to have dir=ltr by default on <input type=tel> (no dir attribute at all), I do *not* think that it is worth making a special case for <input type=tel dir=auto>. We are primarily talking about <textarea>, <input type=text> and other elements here, which may well be used to enter/dispay a phone number.

After your change, the spec now says:

--> If the element's dir attribute is in the rtl state
--> If the element is an input element whose type attribute is in the Telephone state, and the dir attribute is in the auto state
        The directionality of the element is 'rtl'.

The second line needs to be removed, both because it makes the telephone input RTL (it should be LTR) and because I do not think the <input type=tel dir=auto> case is important.

Furthermore, the Telephone state should be restored to the list in:

--> If the element is an input element whose type attribute is in the Text, Search, URL, or E-mail state, and the dir attribute is in the auto state

Instead, if you do want to make <input type=tel> default to LTR (which I think is a good idea), where you now have:

--> If the element is a root element and the dir attribute is not in a defined state (i.e. it is not present or has an invalid value)
        The directionality of the element is 'ltr'.

You should change "a root element" to "a root element or a an input element whose type attribute is in the Telephone state"

> I've made <textarea dir=auto> default to RTL if it contains RTL characters,
> parent if empty, LTR otherwise.

You actually did that not just for <textarea>, but also for <input>, and for all elements except the root element and <bdi>. Looks good, except that I do not think there is any reason to have the special case for <bdi>.

> How about other elements? What direction should this be in?
> 
>    <div dir=rtl>
>      <div dir=auto>1.</div>
>      RTLRTLRTL...
>    </div>
> 
> ...?

That <div dir=auto>1.</div> is non-empty and thus should be LTR. That's what the spec currently says, and that's what I want.
Comment 19 Ian 'Hixie' Hickson 2013-06-11 22:02:49 UTC
Ok, I tried to do as you suggest. Let me know if I missed something again. Thanks!
Comment 20 contributor 2013-06-11 22:03:40 UTC
Checked in as WHATWG revision r7955.
Check-in comment: Another attempt at making directionality in various edge cases more useful and more intuitive.
http://html5.org/tools/web-apps-tracker?from=7954&to=7955
Comment 21 Aharon Lanin 2013-06-13 13:44:37 UTC
First, there are a couple of typos:

- Where the text says "If the element is an input element whose type attribute is in the Telephone state, and the dir attribute is not in a state", it should probably say "... is not in a defined state (i.e. it is not present or has an invalid value)". I am not 100% sure the parenthetical is necessary here yet again (we have it on the preceding line), but the word "defined" does seem to be in order.

- Where you now have "input[type=tel]:ltr", you probably meant "input[type=tel]:dir(ltr)".

Second, I now see that there is a problem with the general dir="auto" case. It is still defaulting to the parent's directionality for all-neutral content, not just for empty content. I know I had said the opposite (that it was doing it only for empty content) in comment 18, but I must have been confused.

The problem is that it is not easy to fix this. What we need to do is to broaden the "Otherwise, if the element is a root element, the directionality of the element is 'ltr'" to include the case where there were any Text nodes fitting the two criteria given above that line.
Comment 22 contributor 2013-06-21 16:01:23 UTC
Checked in as WHATWG revision r7994.
Check-in comment: Fix mistakes with CSS and make 'not in a state' more consistent
http://html5.org/tools/web-apps-tracker?from=7993&to=7994
Comment 23 Ian 'Hixie' Hickson 2013-06-21 16:17:35 UTC
Ok so let me make sure I understand what you want changed here, so we don't keep going around and around.

The _only_ change you now want to the dir="" section, is to replace these two sentences in the dir=auto general case:

    Otherwise, if the element is a root element,
    the directionality of the element is 'ltr'.

    Otherwise, the directionality of the element is
    the same as the element's parent element's directionality.

...with these two sentences:

    Otherwise, if the element is empty and is not a root element, the
    directionality of the element is the same as the element's parent
    element's directionality.

    Otherwise, the directionality of the element is 'ltr'.

Is that exactly right?
Comment 24 Aharon Lanin 2013-06-23 18:58:29 UTC
I had originally meant something a little different: The element does not have to be completely empty of descendants to be considered LTR (regardless of the parent's directionality) - it just mustn't have any text descendants (except those that are descended from a descendant with a dir attribute, etc.). But I now see that this does not make much sense, and think that your current phrasing is exactly right.
Comment 25 Ian 'Hixie' Hickson 2013-07-02 22:58:27 UTC
My current phrasing from comment 23, or my current phrasing in the spec?
(Just making sure I understand, since I've had trouble getting this one right!)
Comment 26 Aharon Lanin 2013-07-03 06:10:51 UTC
I think that your phrasing from comment 23 is exactly right.
Comment 27 contributor 2013-07-03 22:39:29 UTC
Checked in as WHATWG revision r8033.
Check-in comment: Hopefully final fix for automatic directionality.
http://html5.org/tools/web-apps-tracker?from=8032&to=8033