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

[whatwg] Standard method to get/set caret position

From: martijn <martijnw@hotpop.com>
Date: Tue, 31 Aug 2004 00:48:37 +0200
Message-ID: <4133AEC5.2080108@hotpop.com>
Ah, I see. Indeed for shift->left, shift->right, this would be 
beneficial. But I think this is a small benefit against a greater drawback.
It seems the different software is acting differently (even in time), 
but in general the caret is disabled when something is selected, right?
I agree that there should be some option to enable/auto/disable/ the 
caret in the API that would handle selection stuff.

-Martijn

Matthew Thomas wrote:

> Because native Windows editing controls have both -- a selection, and 
> then a caret at either the start or the end of the selection, 
> depending on which direction the selection was made in. (The benefit 
> is that it lets you see which end of the selection 
> Shift+Left/+Right/+Up/+Down will alter; the drawbacks are that 
> Left/Right are less likely to do what you want, and that the blinking 
> caret falsely suggests that typing will not replace the selection.)
>
> But such a caret is not present when a selection is made in MS Word, 
> nor in any Mac software I've seen, nor in MSIE on Windows or Mac OS, 
> and nor in Mozilla on any platform.
>
> <http://bugzilla.mozilla.org/show_bug.cgi?id=41077#c22>
> <http://bugzilla.mozilla.org/show_bug.cgi?id=64643>
> <http://bugzilla.mozilla.org/show_bug.cgi?id=78949>
>
> However, I'd be uncomfortable with any API that prevented the 
> designers of a future OS (for example Jef Raskin's "Humane 
> Environment", if that ever becomes an OS) from deciding that they will 
> have such a caret.
>
Received on Monday, 30 August 2004 15:48:37 UTC

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