10821 2010-09-29 12:58:34 +0000 i18n comment 17 : setting input and textarea element direction through browser UI should set the dir attribute and trigger oninput event 2011-01-22 20:35:56 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Windows XP CLOSED FIXED P2 normal --- 10809 1 public-i18n-bidi ian adrianba aharon.lists.lanin annevk ap ayg bzbarsky ehsan eric fantasai.bugs ian jonas lachlan.hunt mike mjs public-html-admin public-html-wg-issue-tracking public-i18n-bidi roc zcorpan public-html-bugzilla oldest_to_newest 39951 0 public-i18n-bidi 2010-09-29 12:58:34 +0000 Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 17 At http://www.w3.org/International/reviews/html5-bidi/ Editorial/substantive: S Tracked by: AL Location in reviewed document: undefined [http://dev.w3.org/html5/spec/spec.html#contents] Comment:This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#set-direction [http://www.w3.org/International/docs/html-bidi-requirements/#set-direction] . Here is the proposal made there: The HTML specification should state that when the user agent user interface allows the user to set the direction of <input> and <textarea> elements, it will: - Set the element's dir attribute value accordingly. - Trigger the oninput event after the dir attribute has been set. Even though no actual input took place, the user changed the recommended interpretation of the input already collected. 40812 1 ian 2010-10-07 21:34:43 +0000 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? 40831 2 ehsan 2010-10-08 02:32:47 +0000 (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. 41045 3 ian 2010-10-12 09:47:35 +0000 What would you recommend in the case where a <textarea> has two paragraphs, and the user sets different directionality for each paragraph? 41231 4 aharon.lists.lanin 2010-10-13 15:22:54 +0000 (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. 41247 5 ian 2010-10-13 18:17:27 +0000 > It is not perfect, but I do not like adding control characters to the current > paragraph Why not? 41392 6 ian 2010-10-15 00:14:14 +0000 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. 41498 7 ayg 2010-10-18 18:46:56 +0000 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. 41505 8 ehsan 2010-10-18 21:44:32 +0000 (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. 41525 9 ian 2010-10-19 06:34:30 +0000 Can't it just autodetect the direction like the bidi algorithm says to? 41580 10 ayg 2010-10-19 16:44:57 +0000 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. 41621 11 ehsan 2010-10-20 23:30:28 +0000 (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. 41743 12 aharon.lists.lanin 2010-10-26 02:22:29 +0000 (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. 41744 13 928 aharon.lists.lanin 2010-10-26 02:24:05 +0000 Created attachment 928 Check whether your browser sets an input's dir when you change its direction. 41745 14 aharon.lists.lanin 2010-10-26 02:25:57 +0000 (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. 42012 15 ian 2010-11-03 08:14:14 +0000 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? 42015 16 ian 2010-11-03 08:27:53 +0000 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. 42035 17 aharon.lists.lanin 2010-11-03 14:54:47 +0000 (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. 42073 18 ian 2010-11-03 18:56:33 +0000 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. 42087 19 contributor 2010-11-03 23:14:20 +0000 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 42088 20 aharon.lists.lanin 2010-11-03 23:42:03 +0000 (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. 42091 21 aharon.lists.lanin 2010-11-03 23:49:48 +0000 (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? 42105 22 ian 2010-11-04 07:20:57 +0000 (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? 42143 23 aharon.lists.lanin 2010-11-04 22:11:06 +0000 (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. 42158 24 ian 2010-11-05 01:16:29 +0000 Oops, I saw comment 2 saying no, and missed comment 12. Sorry about that. 42164 25 ian 2010-11-05 07:25:44 +0000 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. 42192 26 ap 2010-11-05 16:12:36 +0000 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). 42195 27 bzbarsky 2010-11-05 16:26:22 +0000 Seems fine to me. 42234 28 ian 2010-11-08 08:03:38 +0000 Would anybody object to this being a new event? Or is it important that it be 'input'? 42238 29 annevk 2010-11-08 08:30:28 +0000 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.) 42239 30 mjs 2010-11-08 08:50:11 +0000 (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. 42240 31 annevk 2010-11-08 08:52:36 +0000 And just so I get this right, I guess for the contenteditable="" scenario the logic is that the application will handle all the details? 42246 32 aharon.lists.lanin 2010-11-08 10:58:17 +0000 (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. 42259 33 aharon.lists.lanin 2010-11-08 11:47:31 +0000 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. 42265 34 annevk 2010-11-08 12:03:34 +0000 New events can be introduced outside of DOM Level 3 Events. (And that happens quite often.) 42370 35 ian 2010-11-10 17:30:18 +0000 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. 42399 36 ian 2010-11-11 00:45:41 +0000 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. 928 2010-10-26 02:24:05 +0000 2010-10-26 02:24:05 +0000 Check whether your browser sets an input's dir when you change its direction. setdir.html text/html 787 aharon.lists.lanin PGh0bWw+DQo8aGVhZD48dGl0bGU+RWZmZWN0IG9mIHNldHRpbmcgZGlyZWN0aW9uIG9uIERPTTwv dGl0bGU+PC9oZWFkPg0KPGJvZHkgb25sb2FkPSJzZXRGb2N1cygpIj4NCiAgPHA+VG8gY2hhbmdl IHRoZSBpbnB1dCdzIGRpcmVjdGlvbjo8L3A+DQogIDx1bD4NCiAgICA8bGk+SUUsIENocm9tZSAm IE9wZXJhOiBDdHJsIC0gUmlnaHQgU2hpZnQ8L2xpPg0KICAgIDxsaT5GaXJlZm94OiBDdHJsIC0g U2hpZnQgWDwvbGk+DQogICAgPGxpPlNhZmFyaTogcmlnaHQtY2xpY2ssICJTZXQgcGFyYWdyYXBo IGRpcmVjdGlvbiI8L2xpPg0KICA8L3VsPg0KICA8cD5BZnRlciBjaGFuZ2luZyB0aGUgaW5wdXQn cyBkaXJlY3Rpb24sIGNsaWNrIG9uICdDaGVjayBkaXJlY3Rpb24nLjwvcD4NCiAgPGlucHV0IGlk PXggdHlwZT10ZXh0Lz4NCiAgPGlucHV0IHR5cGU9YnV0dG9uIHZhbHVlPSJDaGVjayBkaXJlY3Rp b24iIG9uY2xpY2s9ImNoZWNrRGlyZWN0aW9uKCkiIC8+DQogIDxzY3JpcHQ+DQogICAgdmFyIHgg PSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgneCcpOw0KICAgIGZ1bmN0aW9uIHNldEZvY3VzKCkg ew0KICAgICAgeC5mb2N1cygpOw0KICAgIH0NCiAgICBmdW5jdGlvbiBjaGVja0RpcmVjdGlvbigp IHsNCiAgICAgIGFsZXJ0KCd4LmRpcjogIicgKyB4LmRpciArDQogICAgICAgICAgJyI7IHguZ2V0 QXR0cmlidXRlKFwnZGlyXCcpOiAiJyArDQogICAgICAgICAgeC5nZXRBdHRyaWJ1dGUoJ2Rpcicp ICsgJyInKTsNCiAgICB9DQogIDwvc2NyaXB0Pg0KPC9ib2R5Pg0KPC9odG1sPg==