- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 12 Nov 2004 10:46:06 +0000 (UTC)
On Sun, 29 Aug 2004 gkilwein at mail.fbsdata.com wrote: > > I've encountered two situations where setting or retrieving the caret > position would be useful. The first is a situation where I'd like to > apply an input mask to a text box. For example, I'd like the ability to > create a text box where the date delimiters (dashes or slashes) appear > automatically in a text box upon entering the field, and when the user > types in the field, it fills into the appropriate spaces in the input > box and sets the text selection to the next appropriate position, all > while allowing the user to reposition the cursor within the text box > with a keyboard or mouse without being able to edit or delete the > delimiters (dashes or slashes). This would be very similar to input > mask features in certain native apps that I've used. Indeed, that would definitely need APIs for setting and retrieving the caret position. I've noted this use case and will be sure to address it when I work on the caret stuff. > The second situation is an application that would like to highlight text > in a text box or textarea for the purposes of a spell check, thesaurus, > or search-and-replace operation. In this case you want more of a highlighting API than a selecting API, though, right? > > So I don't know. What do people think? Should we try to be backards > > compatible with the Mozilla interface or the IE interface, or should > > we start from scratch here, and require that people write wrappers > > around the Moz and IE wrappers if they want compatibility? If we use > > something already defined, what do we use? What are the use cases that > > matter? > > I think the IE and Mozilla models are a bit complicated, and it would be > relatively easy to create a wrapper for various UAs. The advantage with being compatible is that old content Just Works. > Here's what I propose: > > Given a text box or textarea that I'll refer to as "tx": > > tx.selectionStart: This is a read/write integer that would set or retrieve > the starting index of the selected text (one-based, so "1" would be > the first character in the string). If nothing is selected, 0 would > be returned. > > tx.selectionEnd: This is a read/write integer that would set or retrieve > the ending index of the selected text (one-based). > > tx.position: This is a read/write integer that would set or retrieve > the position of the caret (again, one-based). > > Given these three very simple ways to access the position of the caret and > text selection, other derivatives available in IE's implementation > (inputrange.text.length, for example) would be trivial to compute > (tx.selectionEnd-tx.selectionStart). Given that the selectionStart and > selectionEnd return 0 if nothing is selected, this would work properly in > the case of length computations. Additionally, it would be easy to > extract the text, given functions such as substring(). > > This would cover everything I've wished for with cursor positioning > within a text box or textarea and would be vastly simpler than what > currently exists. What do others think - is this comprehensive? Is this a > viable solution? That certainly seems simpler; I've noted it (which means it's now in the comment block at the bottom of the web apps spec) and will definitely consider it in more detail in due course. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 November 2004 02:46:06 UTC