This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 19 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/#remember-input-dir [http://www.w3.org/International/docs/html-bidi-requirements/#remember-input-dir] . Here is the proposal made there: The HTML specification should state that whenever a user agent stores a user-provided <input> or <textarea> text value for later use (such as auto-completion), it should also store the nominal direction value the element had when displaying this value. This may be the original direction of the element, or may have been set by the user for that value via the user agent's UI, or may have been set for that value by page scripts. If the user agent later recalls and displays this value, e.g. in an auto-completion dropdown, it should be displayed in its stored direction. If the value is assigned to an element, the element's dir value should be set to its stored direction.
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: Rejected Change Description: no spec change Rationale: We definitely don't want session storage state memory mutating the DOM dynamically. In any case, that's unlikely to ever come up, since the page isn't likely to have a different dir="" attribute than it did when the user filled the form the first time. Beyond that, the spec doesn't define how any of the form memory stuff should work, so it's not clear to me that it'd be appropriate to go into this much detail. It's a UI issue, not an interop issue.
(In reply to comment #1) > We definitely don't want session storage state memory mutating the > DOM dynamically. Why not? And anyway, it already does so when it sets the input/textarea's value/content. > In any case, that's unlikely to ever come up, since the page > isn't likely to have a different dir="" attribute than it did when the user > filled the form the first time. It comes up all the time, when the user sets the control's direction via the UI provided by the user agent, which sets the control's dir attribute (see bug 10821). All we are saying is that when the control gets re-populated with a value the user provided in the past, it should be re-populated with the dir that the user explicitly assigned to that value, if any.
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: Partially Accepted Change Description: see diff given below Rationale: The spec doesn't really define the form control value saving feature yet (we'll probably have to spec it in due course), but in the meantime I've added a note to the effect that dir="" can be propagated as well. Hopefully that's sufficient.
Checked in as WHATWG revision r5893. Check-in comment: Mention dir='' in the persisted user state stuff now that the user can change it too. http://html5.org/tools/web-apps-tracker?from=5892&to=5893
The added note is a big step in the right direction. I would prefer if it more clearly gave a recommendation (although still not coming anywhere near normative). Specifically, it would be great to change the "if the persisted state includes the directionality" to "from a persisted state that includes the directionality", and to tack on an additional sentence: "Persisting and using in this manner the directionality of user input values will prevent displaying the values incorrectly on history traversal when the user had originally entered the values with an explicit, non-default directionality."
(In reply to comment #5) > The added note is a big step in the right direction. I would prefer if it more > clearly gave a recommendation (although still not coming anywhere near > normative). Specifically, it would be great to change the "if the persisted > state includes the directionality" to "from a persisted state that includes the > directionality", and to tack on an additional sentence: "Persisting and using > in this manner the directionality of user input values will prevent displaying > the values incorrectly on history traversal when the user had originally > entered the values with an explicit, non-default directionality." "Persisting and using" { COMMENT: this phrase is awkward; I'm still trying to think of a "fix;" I may try to use Aharon's wording elsewhere } "A persisting state that incorporates the directionality of user input values will prevent the values' { QUESTION do you mean "text" or "values" above? sorry to ask a dumb question but what is going to be displayed?} being displayed incorrectly on history traversal, in cases where the user [has] originally entered the values with an explicit, non-default directionality." Best, --C. E. Whitehead cewcathar@hotmail.com
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: I don't understand. Could you elaborate? What is the problem with the current text? Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for me to determine if the problem is endemic (requiring more changes than you realise), or if what I think of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or if stylistic differences are intentional or not, etc.
> Rationale: I don't understand. Could you elaborate? What is the problem with > the current text? It gives no clue why the user agent might want to go through the trouble of persisting the directionality of user inputs or then setting the dir attribute. Clearly, this is not obvious - witness no browser currently doing this, as well as your original response ("In any case, that's unlikely to ever come up, since the page isn't likely to have a different dir attribute than it did when the user filled the form the first time"). I wanted to give such a clue, namely to "prevent displaying the values incorrectly on history traversal when ..."
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 below Rationale: Concurred with comment 8.
Checked in as WHATWG revision r6339. Check-in comment: Add a note about why you would persist dir='' in history traversal. http://html5.org/tools/web-apps-tracker?from=6338&to=6339
Thanks, that's great.
mass-move component to LC1