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.

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?

(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.

(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.

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.

(In reply to comment #5)
> 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.

Right, but it won't handle other directionality specific UI effects that I mentioned in comment 4.

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.

(In reply to comment #7)
> 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 locale 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.

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.

This bug was cloned to create bug 17835 as part of operation convergence.

So I understand that the CSS side is handled, and I tend to agree with Ian's suggestion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835 to defaulting to inherited for regular elements with dir=auto as well. Any further thoughts on this?

(In reply to comment #10)
> So I understand that the CSS side is handled, and I tend to agree with Ian's
> suggestion in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17835 to
> defaulting to inherited for regular elements with dir=auto as well. Any
> further thoughts on this?

Sounds good to me.

(In reply to comment #10)

Repeating my reply to Ian's comment on that bug:

> 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 (these are not part of any spec, but it is what browsers do). 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 goes on to enter RTL text, which is presumably the more common case in an RTL page.
- The scrollbar would appear on the left. This, once again, is better (scrollbar does not jump) in the more common case that the user goes on to enter RTL text.
- The resize control would appear on the left, which usually (but not always) makes it work better. Noite, however, that this is browser-dependent and subject to change.

The same considerations probably apply 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".

So, bottom line, I agree.

First patch applied from WHATWG:
https://github.com/w3c/html/commit/0a07a511bb618f1c220556837bada45174712d1f

WHATWG bug is re-opened, so I'm not closing this either.

Additional patch from WHATWG applied:

https://github.com/w3c/html/commit/2f0e48497d968d82040abad6a107702b4fefbbda

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted

Change Description: 
https://github.com/w3c/html/commit/3798b9ca9030c28fbb66512f24d3ab1b7bfa5ec5

Rationale: applied WHATWG fix