Regarding the first issue, setting the "dir" attribute:

- Do any implementations do this?

- If not:
    - What problem does doing this solve?
    -  What do implementations currently do instead?

(In reply to comment #1)
> Regarding the first issue, setting the "dir" attribute:
> 
> - Do any implementations do this?

Not yet, to the best of my knowledge.

> - If not:
>     - What problem does doing this solve?

See below please.

>     -  What do implementations currently do instead?

Gecko sets the dir attribute on an internal DIV element which it uses to render the input/textarea contents.  This DIV element is not exposed to the web page DOM, and is entirely inaccessible to the page.

One problem, for example, is that if the page uses the dir attribute to switch the input/textarea direction, this will override what the page specify, and there will be no way for the web page to toggle the direction once the user uses the browser UI provided mechanism for switching text direction.

Another problem is that without the dir attribute set on the input/textarea element, the page does not have any way to determine the real direction of the element, and any script which relies on this knowledge will malfunction.

What would you recommend in the case where a <textarea> has two paragraphs, and the user sets different directionality for each paragraph?

(In reply to comment #3)
> What would you recommend in the case where a <textarea> has two paragraphs, and
> the user sets different directionality for each paragraph?

As currently proposed, the direction of the textarea of the whole would be set, and thus that of all its paragraphs, not an individual paragraph. Thus, we would not treat a textarea any differently from (a single-line) input.

It is not perfect, but I do not like adding control characters to the current paragraph, and there is nothing else.

> It is not perfect, but I do not like adding control characters to the current
> paragraph

Why not?

Whatever we do here it should probably work closely with the solution we come up with for telling the server what the direction was when the textarea or text field is submitted.

Control characters are evil -- in normal text editors they're hard to type, impossible to see, and hard to delete even if you can find them.  They should be necessary as infrequently as possible.

It would be useful to have a concrete example of a script that would like to know when the user changes textarea/input directionality.  I can't think of one offhand.

(In reply to comment #7)
> It would be useful to have a concrete example of a script that would like to
> know when the user changes textarea/input directionality.  I can't think of one
> offhand.

A very common use case would be a webmail email client, which wants to generate the correct HTML version for an email typed in a textarea element by the user, possibly in the opposite direction as the base direction of the webmail client's web page.

Can't it just autodetect the direction like the bidi algorithm says to?

No, because maybe the user explicitly set the direction in a way that contradicts the Unicode bidi rules.  For instance, if the overall page direction is LTR and I type something in a field in RTL, that will be displayed LTR as I type it, which is weird if there's punctuation at the beginning or end:

Logical: HEBREW!
Correct display: !WERBEH
Actual display: WERBEH!

Thus I might use a keyboard shortcut like Ctrl-Shift-X in Firefox to switch direction.  (Although that actually seems to do something other than simply set dir="rtl" -- it looks more like it sets dir="rtl" only for paragraphs containing an RTL character, or something.)  This is information that could be useful to scripts, e.g., so that when the value is later output it can be given the correct direction, a la bug 10809.

(In reply to comment #10)
> (Although that actually seems to do something other than simply set
> dir="rtl" -- it looks more like it sets dir="rtl" only for paragraphs
> containing an RTL character, or something.)

FWIW, that keyboard shortcut sets the dir attribute on an internal <div> element used to display the contents of <input> and <textarea> elements.

(In reply to comment #1)
> Regarding the first issue, setting the "dir" attribute:
> 
> - Do any implementations do this?

Yes, IE, Chrome, and Safari do. By "set the dir attribute" I mean that both element.dir and element.getAttribute('dir') now return the new value, either 'ltr' or 'rtl'.

Firefox and Opera, however, do not reflect the change of direction in the DOM as far as I can tell; element.dir and element.getAttribute('dir') remain unchanged.

Attaching an HTML file that demonstrates this.

Created attachment 928 [details]
Check whether your browser sets an input's dir when you change its direction.

(In reply to comment #3)
> What would you recommend in the case where a <textarea> has two paragraphs, and
> the user sets different directionality for each paragraph?

No browser supports such an action. In all, setting the direction on a textarea acts on the whole textarea, i.e. all the paragraphs in it, not just the one in which the cursor may have been.

Assuming we fix 10809 (i.e. given an opt-in, we expose the direction in the submitted data, and possibly in the textarea value as well), what use cases relevant to this bug would remain unaddressed?

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: Did Not Understand Request
Change Description: no spec change
Rationale: See comment 15. Awaiting clear problem description.

(In reply to comment #15)
> Assuming we fix 10809 (i.e. given an opt-in, we expose the direction in the
> submitted data, and possibly in the textarea value as well), what use cases
> relevant to this bug would remain unaddressed?

Scripts might want to do a lot more than just report the direction chosen by the user to the server!

Use case: Google Forms. The product uses the direction of the form's title for the direction of the form overall, e.g. whether the form should be left- or right-aligned. The title's direction is auto-estimated in scripts handling keyboard events on the title input. Thus, as soon as the user types RTL text into (the initially LTR) title input, the form, as seen in the (partially WYSISWYG) form editor, flips to RTL. This is long before anything is submitted to the server and thus before submitdir would have any utility.

Unfortunately, if the user sets the title's direction explicitly using the browser-provided method for doing so, this is invisible to the app's scripts in Firefox, Opera and Safari, so the app paradoxically can't set the form's direction in this "obvious" case.

The proposed solution for bug 10809 would expose the direction to script (it'd be the first character of the value), so that use case seems like it'd be handled.

Checked in as WHATWG revision r5668.
Check-in comment: Added example of select directionality issue
http://html5.org/tools/web-apps-tracker?from=5667&to=5668

(In reply to comment #19)
> Checked in as WHATWG revision r5668.
> Check-in comment: Added example of select directionality issue
> http://html5.org/tools/web-apps-tracker?from=5667&to=5668

I think that comment was meant to go in bug 10819.

(In reply to comment #18)
> The proposed solution for bug 10809 would expose the direction to script (it'd
> be the first character of the value), so that use case seems like it'd be
> handled.

1. As you can see in the comments on bug 10809, I strenuously object to that proposed solution (wrapping the value in bidi formatting characters when the user sets the direction on an input or textarea element that has the submitdir attribute) on the grounds that bidi formatting characters are evil in an abundant variety of ways. If this is how submitdir worked, I would be the first to recommend not to use it.

2. As I keep pointing out in comments on bug 10809, you can't get the user-set direction just by checking the first character of the value. If the first character is indeed LRE or RLE, you would then still have to scan right through the whole string to make sure that its balancing PDF is the last character of the string. And no, you can't just look at the first and last character of the string, because the last character might be a PDF, but might not be the balancing PDF of the leading formatting character. Example: "[RLE]JOE[PDF] would like to congratulate [RLE]SUSAN[PDF]". I think about one in five web developers who attempt to do this will get it right, and that's being optimistic.

3. The proposed solution does not address the current lack of interoperability, where some browsers set the input's dir attribute, and some don't - unless you are also proposing adding to the specification that the user's setting the direction should not set the dir attribute (regardless of whether submitdir is on). Is this something you really want to do?

4. All browsers change the effective alignment of the input when the user sets its direction. This is important visual feedback, and users expect it. If you propose to specify that the user setting the direction should not set the dir attribute, what justification is there for changing the effective alignment?

(In reply to comment #21)
> 1. As you can see in the comments on bug 10809, I strenuously object to that
> proposed solution (wrapping the value in bidi formatting characters when the
> user sets the direction on an input or textarea element that has the submitdir
> attribute) on the grounds that bidi formatting characters are evil in an
> abundant variety of ways. If this is how submitdir worked, I would be the first
> to recommend not to use it.

The details of the solution to bug 10809 aren't important here; the point is that the information would be exposed to script one way or another, so the use case described above is possible to do with that solution in place.


> 2. As I keep pointing out in comments on bug 10809, you can't get the user-set
> direction just by checking the first character of the value. If the first
> character is indeed LRE or RLE, you would then still have to scan right through
> the whole string to make sure that its balancing PDF is the last character of
> the string.

That's a discussion for that bug.


> 3. The proposed solution does not address the current lack of interoperability,
> where some browsers set the input's dir attribute, and some don't - unless you
> are also proposing adding to the specification that the user's setting the
> direction should not set the dir attribute (regardless of whether submitdir is
> on). Is this something you really want to do?

I don't understand what this is is referring to. What browsers affect the DOM? Can you attach a test case showing the interoperability problem? Is that the problem this bug is trying to fix? If this is a separate issue, please file a separate bug for it.


> 4. All browsers change the effective alignment of the input when the user sets
> its direction. This is important visual feedback, and users expect it. If you
> propose to specify that the user setting the direction should not set the dir
> attribute, what justification is there for changing the effective alignment?

This doesn't seem related to this bug, which is (as far as I can tell) about scripts being able to tell what direction the user has picked, when the user picks it.

In any case, why would you need any justification? It's a form control, the browser could display it with characters alternating alignment every two seconds and it would still be conforming to the HTML spec. That's a presentational matter. HTML is by design presentation-agnostic.


Anyway. It seems like simply making sure that the data that is submitted for bug 10809 is also available in the DOM, and that events are fired when it changes, would resolve this bug, right?

(In reply to comment #22)
> (In reply to comment #21)
> > 3. The proposed solution does not address the current lack of interoperability,
> > where some browsers set the input's dir attribute, and some don't - unless you
> > are also proposing adding to the specification that the user's setting the
> > direction should not set the dir attribute (regardless of whether submitdir is
> > on). Is this something you really want to do?
> 
> I don't understand what this is is referring to. What browsers affect the DOM?

Please see comment 12.

> Can you attach a test case showing the interoperability problem?

I already did, at the same time that I added comment 12.

> Anyway. It seems like simply making sure that the data that is submitted for
> bug 10809 is also available in the DOM, and that events are fired when it
> changes, would resolve this bug, right?

Ok, if you can find some way to shoot those two birds with one stone, and the stone does not happen to be formatting characters. :-)

And I think I'll leave the interoperability problem up to you, too.

Oops, I saw comment 2 saying no, and missed comment 12. Sorry about that.

Could browser vendors comment on whether they would be interested in changing behaviour here?

The question specifically is on whether when the user changes a text field from ltr to rtl (or vice versa), the user agent should mutate the DOM to set a dir="" attribute on the <input> or <textarea> element to the selected direction.

As mentioned in comment 12, WebKit implements the proposed behavior, and it seems reasonable to me. A script can detect direction for <div contenteditable> via DOM attributes (although not uniformly across browsers), so having such a way for input and contenteditable only makes sense.

Firing oninput would seem strange though (I don't see any difference with e.g. changing style to bold in contenteditable).

Seems fine to me.

Would anybody object to this being a new event? Or is it important that it be 'input'?

Would mutation events or their replacement not cover this? (If a generic event such as 'input' is sufficient, mutation events or their replacement should be too.)

(In reply to comment #29)
> Would mutation events or their replacement not cover this? (If a generic event
> such as 'input' is sufficient, mutation events or their replacement should be
> too.)

I think the idea of using "input" is so that generic form validation code or autocomplete code will re-run if the direction changed. It seems more likely and more effective to check for form control contents changing using the "input" event as opposed to mutation events. So if an event is going to be reused, "input" probably makes more sense. On the other hand, a new event may be ok as well, since many Web apps will not look at the dir attribute anyway.

And just so I get this right, I guess for the contenteditable="" scenario the logic is that the application will handle all the details?

(In reply to comment #30)
> (In reply to comment #29)
> I think the idea of using "input" is so that generic form validation code or
> autocomplete code will re-run if the direction changed. It seems more likely
> and more effective to check for form control contents changing using the
> "input" event as opposed to mutation events. So if an event is going to be
> reused, "input" probably makes more sense. On the other hand, a new event may
> be ok as well, since many Web apps will not look at the dir attribute anyway.

This justification for using the "input" sounds good to me, although of course I would be ok with a new event too.

I would hate to have to rely on a mutation event. DOM2 mutation events have not been interoperably implemented, and are currently deprecated in DOM3. Specifically, DOMAttrModified has not been implemented in WebKit and it is generally unclear whether DomAttrModified is supposed to be triggered on attribute changes done via the browser UI, not via script. As for DOMSubtreeModified, while it is implemented in WebKit, it only seems to be triggered by the initial addition of the dir attribute, but not when its value changes. Furthermore, it has not been implemented in Opera.

If we really think that a new event for this purpose is viable, doesn't this affect the DOM3 events spec? If so, it needs to be proposed there immediately, so let's please come to a decision on this ASAP.

New events can be introduced outside of DOM Level 3 Events. (And that happens quite often.)

Using 'input' to trigger the revalidation code makes sense. I'll use that.

So in summary, the change here is to require that dir="" on the element get mutated when the user uses a UI that changes the writing direction of a text field, and that the 'input' event be fired (async) when that happens.

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: see diff given in bug 10809 comment 48.
Rationale: Concurred with reporter's comments.