On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig <span dir="ltr"><<a href="mailto:shezbaig.wk@gmail.com" target="_blank">shezbaig.wk@gmail.com</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are in the process of porting our native Windows application from<br>
using a proprietary rendering framework to using WebKit as our<br>
rendering framework. Our application is not Chrome, neither is it<br>
Safari, Firefox, or Opera. In fact, it isn't a web browser at all.<br>
<br>
Throughout this effort, we've come across many instances where we have<br>
had to modify WebKit in order to make our application work the way our<br>
users expect it to. All these changes are maintained in our own<br>
private fork, which we frequently merge with upstream.<br>
<br>
Yes, our users *do* expect overtype mode to work, and yes, we do want<br>
a blinking block cursor, however I consider that as an orthogonal<br>
setting and not necessarily tied to overtype mode. The way I<br>
envisioned this would be that the embedding application would set a<br>
property on the contenteditable div to turn on/off the overtype mode,<br>
based on some UI interaction (whether it is via the Insert key, or<br>
some menu command is up to the application). When the contenteditable<br>
is in overtype mode, this essentially makes TypingCommand replace the<br>
next character instead of inserting characters. This is a behavior<br>
change *only*, not a visual change.<br>
<br>
When the application switches the overtype mode on/off, it would also<br>
at the same time modify the appearance of the cursor (in our app, this<br>
will be done via non-standard css properties, like "caret-width" and<br>
"caret-color", and yes, we only plan use this for fixed-width fonts).<br></blockquote><div><br></div><div>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:</div>
<div>123CBA</div><div><br>If we were to place logical/DOM offset at where they appear visually, we have:</div><div>(0)1(1)2(2)3C(5)B(4)A(3)(6)</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It might also change the border color of the contenteditable. My<br>
point is that the visual appearance to indicate that we are in<br>
overtype mode is not something I would expect WebKit to control. So<br>
I'd rather leave discussion of the appearance separate from the<br>
functionality/behavior itself.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I guess the question boils down to something like: if we have<br>
changes that are generally useful, but not used in the major WebKit<br>
applications (i.e. Chrome, Safari, Opera), does it make sense to<br>
upstream it to WebKit for the benefit of the general community?<br></blockquote><div><br></div><div>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</div>
<div><br></div><div>- R. Niwa</div><div><br></div></div>