On Mon, Mar 11, 2013 at 9:11 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig <shezbaig...@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) > Oh oops, I'm sorry. I messed this up. It should be: (0)1(5)2(4)3C(2)B(1)A(3)(6) instead. 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. > - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
