W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] Standard method to get/set caret position

From: Greg Kilwein <gkilwein@fbsdata.com>
Date: Sun, 29 Aug 2004 18:40:04 -0500 (CDT)
Message-ID: <Pine.LNX.4.44.0408291834480.10459-100000@mail.fbsdata.com>
On Sun, 29 Aug 2004, Neil Deakin wrote:
> >I think the IE and Mozilla models are a bit complicated, and it would be
> >relatively easy to create a wrapper for various UAs.  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).
> Mozilla uses this same properties except they are zero-based which is 
> more sensible. If nothing is selected, both have the same value (in 
> Mozilla, there is always a selection, though it may be collapsed to a 
> single point). Also, when specifying this you need to be clear that you 
> mean that the cursor should be before or after the character.

Ah, I see what you mean.  That makes sense and prefer the zero-based idea 
since there would always be a value for selectionStart and selectionEnd.  
The index would be the position before the character.  The index of the 
selection that would include the last character would be string.length.

> >tx.position: This is a read/write integer that would set or retrieve
> >   the position of the caret (again, one-based).
> >
> This should be given a more specific name such as cursorPosition or 
> caretPosition, so that it is clear what it's referring to. Otherwise, 
> someone might think it was a screen position.

Great idea.  I prefer caretPosition and a zero-based indexing scheme to 
match selectionStart and selectionEnd.
Received on Sunday, 29 August 2004 16:40:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC