[webkit-dev] Overtype mode in WebKit for editable content?

[Ryosuke Niwa]

On Mon, Mar 11, 2013 at 9:11 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig <shezbaig.wk at gmail.com>wrote:
>
>> We are in the process of porting our native Windows application from
>> using a proprietary rendering framework to using WebKit as our
>> rendering framework.  Our application is not Chrome, neither is it
>> Safari, Firefox, or Opera.  In fact, it isn't a web browser at all.
>>
>> Throughout this effort, we've come across many instances where we have
>> had to modify WebKit in order to make our application work the way our
>> users expect it to.  All these changes are maintained in our own
>> private fork, which we frequently merge with upstream.
>>
>> Yes, our users *do* expect overtype mode to work, and yes, we do want
>> a blinking block cursor, however I consider that as an orthogonal
>> setting and not necessarily tied to overtype mode.  The way I
>> envisioned this would be that the embedding application would set a
>> property on the contenteditable div to turn on/off the overtype mode,
>> based on some UI interaction (whether it is via the Insert key, or
>> some menu command is up to the application).  When the contenteditable
>> is in overtype mode, this essentially makes TypingCommand replace the
>> next character instead of inserting characters.  This is a behavior
>> change *only*, not a visual change.
>>
>> When the application switches the overtype mode on/off, it would also
>> at the same time modify the appearance of the cursor (in our app, this
>> will be done via non-standard css properties, like "caret-width" and
>> "caret-color", and yes, we only plan use this for fixed-width fonts).
>>
>
> Have you tested your code with bidirectional text?  I don't think using
> block caret will work due to the way offsets at bidi-level boundary works
> in WebKit. In particular, suppose we have, in the document/byte order,
> ABC123 where ABC are strongly RTL letters in a LTR block. Then this text is
> rendered as:
> 123CBA
>
> If we were to place logical/DOM offset at where they appear visually, we
> have:
> (0)1(1)2(2)3C(5)B(4)A(3)(6)
>
> i.e. At offset 3, the caret will visually appear on the right of "A". If
> you were just setting the caret width, the caret will look as if we're
> inserting a character on the right of "A", which is extremely misleading to
> a user.
>
> It might also change the border color of the contenteditable.  My
>> point is that the visual appearance to indicate that we are in
>> overtype mode is not something I would expect WebKit to control.  So
>> I'd rather leave discussion of the appearance separate from the
>> functionality/behavior itself.
>>
>
> I agree with that statement but letting applications mess with the
> shape/color of caret is a dangerous game to play since a lot of application
> developers don't know how CJK and RTL text work in WebKit.
>
> So I guess the question boils down to something like: if we have
>> changes that are generally useful, but not used in the major WebKit
>> applications (i.e. Chrome, Safari, Opera), does it make sense to
>> upstream it to WebKit for the benefit of the general community?
>>
>
> Yes. It makes a lot of sense for this feature to be in WebKit. We can
> probably expose some member functions on Editor or add new execCommand only
> executable via menu/keyboard binding to toggle this feature.  I don't think
> it makes a sense for WebCore to detect Insert Key and automatically move
> into the inse
>

move into the overtype mode.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130311/34063e32/attachment.html>