- From: <bugzilla@jessica.w3.org>
- Date: Tue, 10 May 2011 20:37:02 +0000
- To: public-html-bugzilla@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 the QA contact for the bug.
Received on Tuesday, 10 May 2011 20:37:04 UTC