So what's the story here? Should the HTML spec change or not?

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

I would be fine with us proceeding with bug 16564 comment 5, which would be a CSS change.  fantasai: do you agree?

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

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?

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

Ok, I tried to make dir=auto defer to the parent in some cases.

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

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.

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.

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?

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

Ah, ok. That makes some sense.

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?

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

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>

...?

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

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

Ok, I tried to do as you suggest. Let me know if I missed something again. Thanks!

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

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.

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

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?

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.

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!)

I think that your phrasing from comment 23 is exactly right.

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