- From: <bugzilla@jessica.w3.org>
- Date: Tue, 10 May 2011 20:37:02 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12644 Summary: Specify the initial selection state for textarea elements Product: HTML WG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: ehsan@mozilla.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org Here's what the current spec says about the initial selection status for textarea elements <http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#dom-textarea/input-setselectionrange>: "User agents should follow platform conventions to determine their initial state." This makes it really hard for web applications to be able to tell what's going to happen when a textarea element is focused. The current Gecko behavior here is that we set the selection to the end of the textarea. The reason that we've historically done that is a by-product of an implementation detail, and it has not been a conscious decision (see https://bugzilla.mozilla.org/show_bug.cgi?id=612129#c18). The current WebKit behavior is that it sets the selection to the beginning of the textarea. The WebKit's code points to https://bugs.webkit.org/show_bug.cgi?id=11746#c15 as a rationale. I personally think that the WebKit behavior is better since it means that the textarea won't scroll when first focused, which seems to be what web authors expect. I'm switching the Gecko behavior to set the selection to the beginning of the textarea too. It would be great if the HTML5 spec specifies this behavior in order to prevent discrepancy between UAs. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Tuesday, 10 May 2011 20:37:04 UTC