Re: [webkit-dev] Overtype mode in WebKit for editable content?
En 12/03/13 18:31, Ryosuke Niwa escribiu: That doesn't work. At a bidi-level boundary, offset can jump from one place to another. Consider a much simpler example; the same sequence of letters, in logical order, ABC123 in a RTL block, which will be rendered as: 123CBA with logical/DOM offsets placed at: (6)1(4)2(5)3(3)C(2)B(1)A(0) Again, at offset 3, what we're going to replace is 1 so we can't place the block caret on top of either C or 3. The problem is that such kind of weird behaviors are happening now without overtype mode. For example consider the strongly LTR letters abc inside a RTL block, which will be rendered as abc. If we either place the caret at the beginning (before 'a') or at the end (after 'c') the next typed character will be placed at the opposite side the user might expect based on the caret position. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin svil...@igalia.comwrote: En 12/03/13 18:31, - R. Niwa escribiu: That doesn't work. At a bidi-level boundary, offset can jump from one place to another. Consider a much simpler example; the same sequence of letters, in logical order, ABC123 in a RTL block, which will be rendered as: 123CBA with logical/DOM offsets placed at: (6)1(4)2(5)3(3)C(2)B(1)A(0) Again, at offset 3, what we're going to replace is 1 so we can't place the block caret on top of either C or 3. The problem is that such kind of weird behaviors are happening now without overtype mode. No. For example consider the strongly LTR letters abc inside a RTL block, which will be rendered as abc. If we either place the caret at the beginning (before 'a') or at the end (after 'c') the next typed character will be placed at the opposite side the user might expect based on the caret position. That's expected. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA And this is why just setting the width of caret will never work. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.comwrote: I know that WK follows the NSTextView implementation but FF for example does not show the remote insert issue. Yes, it does. Firefox simply uses heuristics to guess which type of character LTR/RTL you're about to type. They still have the same issue. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA Yeah I understood you example, it was very descriptive. What I wanted to share with you is that, in your same example, in Insert mode, placing the caret at (3) will insert the next character before the 1. Isn't that insane too? No. The caret simply shows the logical insertion point. And this is why just setting the width of caret will never work. Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.comwrote: I know that WK follows the NSTextView implementation but FF for example does not show the remote insert issue. Yes, it does. Firefox simply uses heuristics to guess which type of character LTR/RTL you're about to type. They still have the same issue. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA Yeah I understood you example, it was very descriptive. What I wanted to share with you is that, in your same example, in Insert mode, placing the caret at (3) will insert the next character before the 1. Isn't that insane too? No. The caret simply shows the logical insertion point. And this is why just setting the width of caret will never work. Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because it's the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. Of course, we need to pretend as if the selection is collapsed still in JavaScript APIs. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.com wrote: I know that WK follows the NSTextView implementation but FF for example does not show the remote insert issue. Yes, it does. Firefox simply uses heuristics to guess which type of character LTR/RTL you're about to type. They still have the same issue. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA Yeah I understood you example, it was very descriptive. What I wanted to share with you is that, in your same example, in Insert mode, placing the caret at (3) will insert the next character before the 1. Isn't that insane too? No. The caret simply shows the logical insertion point. And this is why just setting the width of caret will never work. Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because it's the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. Of course, we need to pretend as if the selection is collapsed still in JavaScript APIs. - R. Niwa Wouldn't it be sufficient to just modify CaretBase::updateCaretRect to return a rect that covers the next character? Or am I missing something? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 10:07 AM, Shezan Baig shezbaig...@gmail.com wrote: On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.com wrote: I know that WK follows the NSTextView implementation but FF for example does not show the remote insert issue. Yes, it does. Firefox simply uses heuristics to guess which type of character LTR/RTL you're about to type. They still have the same issue. The problem here is that caret will be on top of a wrong character. That's much worse than a character being inserted at a remote location. Using my existing example, what user sees is: 123CBA or 123CBA yet what will be replaced is 1. That's insane. This is orders of magnitude worse than caret showing up as a vertical line at this location: 123|CBA Yeah I understood you example, it was very descriptive. What I wanted to share with you is that, in your same example, in Insert mode, placing the caret at (3) will insert the next character before the 1. Isn't that insane too? No. The caret simply shows the logical insertion point. And this is why just setting the width of caret will never work. Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because it's the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. Of course, we need to pretend as if the selection is collapsed still in JavaScript APIs. Wouldn't it be sufficient to just modify CaretBase::updateCaretRect to return a rect that covers the next character? Or am I missing something? No. That was the whole point of my example and argument. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
En 12/04/13 19:00, Ryosuke Niwa escribiu: On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.com Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. Ok, sounds like a very different approach. Just to clarify, do you mean to skip the caret painting in overtype mode and just use the 1-character selection as if it were the caret? BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Fri, Apr 12, 2013 at 11:59 AM, Sergio Villar Senin svil...@igalia.comwrote: En 12/04/13 19:00, Ryosuke Niwa escribiu: On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin svil...@igalia.com Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. That doesn't sound right either. It's much more confusing than not setting any width at all because the overtype mode is still on. What we need to do is here to use selection. We need to have 1-character long text selection at all time except at the end of each line when overtype is on since selection code already deals with the said bidi craziness. Anything short of that isn't landable quality. Ok, sounds like a very different approach. Just to clarify, do you mean to skip the caret painting in overtype mode and just use the 1-character selection as if it were the caret? Right. In practice, we might be able to do the opposite in the rendering side. Treat overtype caret as if it's 1-character selection when we update the RenderView. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
En 12/03/13 05:11, Ryosuke Niwa escribiu: 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 Will handle it here http://wkb.ug/112126 then. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa rn...@webkit.org wrote: 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. Our application right now doesn't allow for bidi text, so this isn't currently an issue for us. I haven't looked at the details, but if we were to support this in the future, I think the caret rendering code would simply determine whether the next character is RTL or not, and if so, it would extend its width in the opposite direction. Also, I don't understand why offset 3 would be rendered after A -- shouldn't it be rendered before 1 since that is where the next character would be inserted? (or maybe between 3 and C, I'm not familiar enough with the bidi rules). If it is rendered after A right now, then I'm guessing that is just a bug, and whether or not the caret is 1px or 20px wide seems equally misleading to the user. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Tue, Mar 12, 2013 at 8:29 AM, Shezan Baig shezbaig...@gmail.com wrote: On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa rn...@webkit.org wrote: 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. Our application right now doesn't allow for bidi text, so this isn't currently an issue for us. I haven't looked at the details, but if we were to support this in the future, I think the caret rendering code would simply determine whether the next character is RTL or not, and if so, it would extend its width in the opposite direction. That doesn't work. At a bidi-level boundary, offset can jump from one place to another. Consider a much simpler example; the same sequence of letters, in logical order, ABC123 in a RTL block, which will be rendered as: 123CBA with logical/DOM offsets placed at: (6)1(4)2(5)3(3)C(2)B(1)A(0) Again, at offset 3, what we're going to replace is 1 so we can't place the block caret on top of either C or 3. Also, I don't understand why offset 3 would be rendered after A -- shouldn't it be rendered before 1 since that is where the next character would be inserted? (or maybe between 3 and C, I'm not familiar enough with the bidi rules). If it is rendered after A right now, then I'm guessing that is just a bug, and whether or not the caret is 1px or 20px wide seems equally misleading to the user. There is no rule or specification for this. We followed NSTextView's convention and this is the expected behavior. In particular, it is NOT a bug. If we're supporting the overtype mode with block caret, we need to solve this problem. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Overtype mode in WebKit for editable content?
Hi, I was wondering if WebKit as a project would be interested in having overtype mode support for editable content. This in indeed the mode in which the cursor, when typing, overwrites any text that is present on and after its current location [1]. Looks like something like that could be useful to implement online editing tools. Just for reference, both IE and Opera support it while in Firefox the bug was closed as WONTFIX [2] after a lot of discussion. Thoughts? [1] http://en.wikipedia.org/wiki/Insert_key [2] https://bugzilla.mozilla.org/show_bug.cgi?id=38415 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
Hello Sergio, I personally find overtype a very useful tool in vim/emacs, but it is funny how half the links in the first page of Google results to overtype are about turning it off. That said, it is an interesting tool that all major text editors support, useful if you want to use it and easily ignored if you don't. Luis On Mar 11, 2013 12:06 PM, Sergio Villar Senin svil...@igalia.com wrote: Hi, I was wondering if WebKit as a project would be interested in having overtype mode support for editable content. This in indeed the mode in which the cursor, when typing, overwrites any text that is present on and after its current location [1]. Looks like something like that could be useful to implement online editing tools. Just for reference, both IE and Opera support it while in Firefox the bug was closed as WONTFIX [2] after a lot of discussion. Thoughts? [1] http://en.wikipedia.org/wiki/Insert_key [2] https://bugzilla.mozilla.org/show_bug.cgi?id=38415 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 5:05 AM, Sergio Villar Senin svil...@igalia.comwrote: I was wondering if WebKit as a project would be interested in having overtype mode support for editable content. This in indeed the mode in which the cursor, when typing, overwrites any text that is present on and after its current location [1]. Looks like something like that could be useful to implement online editing tools. Just for reference, both IE and Opera support it while in Firefox the bug was closed as WONTFIX [2] after a lot of discussion. I wouldn't object to implementing it in WebKit. I don't think whether other Web browsers implement this feature or not is really relevant. A more relevant question is whether this feature is expected on some platforms or not. For example, we support emacs key bindings and kill ring to be consistent with NSTextView on Mac. Is it expected that overtype works on Windows or on Linux? e.g. If Edit and RichEdit window classes both support this feature natively on Windows (which I bet they do), then the answer is yes. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Is it expected that overtype works on Windows or on Linux? e.g. If Edit and RichEdit window classes both support this feature natively on Windows (which I bet they do), then the answer is yes. The non-rich edit control on Windows (i.e. Notepad) does not support overtype mode. The rich edit control (Wordpad) does support it. MS Word also uses a rich edit control, and goes further by displaying an explicit normal vs. overtype indicator in its UI. The Chrome omnibox uses a native rich edit control, but in early testing overtype mode always ended up being confusing and annoying, so we disabled it, and we've never had a request to re-enable. I'm not necessarily opposed to plumbing support for overtype mode, but I suspect it may not make sense for all text input controls, e.g. single-line controls; and even if we support it, we may want some mechanism to show the user what mode they're in. Without a visual indicator, it can be surprising and frustrating (which is how it feels to me in Wordpad). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting pkast...@google.com wrote: On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Is it expected that overtype works on Windows or on Linux? e.g. If Edit and RichEdit window classes both support this feature natively on Windows (which I bet they do), then the answer is yes. The non-rich edit control on Windows (i.e. Notepad) does not support overtype mode. The rich edit control (Wordpad) does support it. MS Word also uses a rich edit control, and goes further by displaying an explicit normal vs. overtype indicator in its UI. I see. We already have a notion of editable vs. richly editable so we can enable this feature only inside a richly editable area. I'm not necessarily opposed to plumbing support for overtype mode, but I suspect it may not make sense for all text input controls, e.g. single-line controls; and even if we support it, we may want some mechanism to show the user what mode they're in. We should match whatever the platform norm is. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting pkast...@google.comwrote: On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Is it expected that overtype works on Windows or on Linux? e.g. If Edit and RichEdit window classes both support this feature natively on Windows (which I bet they do), then the answer is yes. The non-rich edit control on Windows (i.e. Notepad) does not support overtype mode. The rich edit control (Wordpad) does support it. MS Word also uses a rich edit control, and goes further by displaying an explicit normal vs. overtype indicator in its UI. I see. We already have a notion of editable vs. richly editable so we can enable this feature only inside a richly editable area. I'm not necessarily opposed to plumbing support for overtype mode, but I suspect it may not make sense for all text input controls, e.g. single-line controls; and even if we support it, we may want some mechanism to show the user what mode they're in. We should match whatever the platform norm is. Well, that's the thing. On Windows there isn't really a platform norm. Even a distinction like editable versus richly editable is not really a user-level concept in Windows, it's more of an implementation distinction, and there definitely is no obvious pattern for which applications or text fields will support overtype mode, or whether there's some sort of visible indicator of it. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 4:58 PM, Peter Kasting pkast...@google.com wrote: On Mon, Mar 11, 2013 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting pkast...@google.comwrote: On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Is it expected that overtype works on Windows or on Linux? e.g. If Edit and RichEdit window classes both support this feature natively on Windows (which I bet they do), then the answer is yes. The non-rich edit control on Windows (i.e. Notepad) does not support overtype mode. The rich edit control (Wordpad) does support it. MS Word also uses a rich edit control, and goes further by displaying an explicit normal vs. overtype indicator in its UI. I see. We already have a notion of editable vs. richly editable so we can enable this feature only inside a richly editable area. I'm not necessarily opposed to plumbing support for overtype mode, but I suspect it may not make sense for all text input controls, e.g. single-line controls; and even if we support it, we may want some mechanism to show the user what mode they're in. We should match whatever the platform norm is. Well, that's the thing. On Windows there isn't really a platform norm. Even a distinction like editable versus richly editable is not really a user-level concept in Windows, it's more of an implementation distinction, and there definitely is no obvious pattern for which applications or text fields will support overtype mode, or whether there's some sort of visible indicator of it. Of course, each application can implement overtype in Edit window class and manually disable it in RichEdit window class but I don't think that's an interesting fact since that's a customization. An application doesn't even have to use either window class to implement a text field; e.g. Microsoft Word. But that doesn't mean there is no platform norm. Just like un-customized NSTextView establishes what's norm on Mac, un-customized Edit and RichText establish what's norm on Windows to a certain extent. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote: un-customized Edit and RichText establish what's norm on Windows to a certain extent. It should read: un-customized Edit and RichEdit establish what's norm on Windows to a certain extent. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Of course, each application can implement overtype in Edit window class and manually disable it in RichEdit window class but I don't think that's an interesting fact since that's a customization. An application doesn't even have to use either window class to implement a text field; e.g. Microsoft Word. (Word actually uses a rich edit control just like Wordpad does, which is why Office ships a newer version of that control's DLL.) But that doesn't mean there is no platform norm. Just like un-customized NSTextView establishes what's norm on Mac, un-customized Edit and RichText establish what's norm on Windows to a certain extent. I think that might make sense from a programmer's perspective, though even there I think you're on thin ice on Windows -- there are so many different controls and frameworks for doing UI that the UX on Windows is much more fragmented in general than on Mac (long one of the complaints of those who prefer Mac OS). I know what the MFC CEdit and CRichEditCtrl do, but I don't anything about, say, WPF UIs. I question whether it makes sense at all from a user's perspective. Users don't know or care what classes are used to implement their applications, they care what the applications do. And from that perspective Windows is all over the place. Wordpad, Word, and Visual Studio all support overtype mode, but all three do it differently (Visual Studio is IMO the best -- it actually changes the cursor from bar to block in overtype mode, which I'd love to see any other app supporting this to adopt, and certainly would want if we turned this on in Chrome for Windows). Notepad, which to almost any user who doesn't open files with LF line endings is the same thing as Wordpad, doesn't, and neither does Firefox or Chrome (today). Third-party editors are all over the place. I think we should decide this based on what is most helpful and least confusing to users. Normally a platform convention is a way of establishing what users will expect, which is why it has any value at all. Here I'm not convinced there's a user expectation of overtype mode in general, and I definitely worry that it has low utility and high annoyance, which make me greatly hesitate. And implementing it for rich text but not plain text on the web seems like a recipe for confusion too -- do normal users understand the distinction and would expect overtype mode in one but not the other? Seems more likely that some people would be frustrated that overtype mysteriously doesn't work sometimes, while others would be confused why every once in a while their text gets eaten, but not in a way they can reproduce consistently. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 5:32 PM, Peter Kasting pkast...@google.com wrote: On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote: Of course, each application can implement overtype in Edit window class and manually disable it in RichEdit window class but I don't think that's an interesting fact since that's a customization. An application doesn't even have to use either window class to implement a text field; e.g. Microsoft Word. (Word actually uses a rich edit control just like Wordpad does, which is why Office ships a newer version of that control's DLL.) But that doesn't mean there is no platform norm. Just like un-customized NSTextView establishes what's norm on Mac, un-customized Edit and RichText establish what's norm on Windows to a certain extent. I think that might make sense from a programmer's perspective, though even there I think you're on thin ice on Windows -- there are so many different controls and frameworks for doing UI that the UX on Windows is much more fragmented in general than on Mac (long one of the complaints of those who prefer Mac OS). I know what the MFC CEdit and CRichEditCtrl do, but I don't anything about, say, WPF UIs. I question whether it makes sense at all from a user's perspective. Users don't know or care what classes are used to implement their applications, they care what the applications do. And from that perspective Windows is all over the place. Wordpad, Word, and Visual Studio all support overtype mode, but all three do it differently (Visual Studio is IMO the best -- it actually changes the cursor from bar to block in overtype mode, which I'd love to see any other app supporting this to adopt, and certainly would want if we turned this on in Chrome for Windows). Notepad, which to almost any user who doesn't open files with LF line endings is the same thing as Wordpad, doesn't, and neither does Firefox or Chrome (today). Third-party editors are all over the place. I think we should decide this based on what is most helpful and least confusing to users. Normally a platform convention is a way of establishing what users will expect, which is why it has any value at all. Here I'm not convinced there's a user expectation of overtype mode in general, and I definitely worry that it has low utility and high annoyance, which make me greatly hesitate. And implementing it for rich text but not plain text on the web seems like a recipe for confusion too -- do normal users understand the distinction and would expect overtype mode in one but not the other? Seems more likely that some people would be frustrated that overtype mysteriously doesn't work sometimes, while others would be confused why every once in a while their text gets eaten, but not in a way they can reproduce consistently. This is a very subjective topic to which I rather not respond. Having said that, I object to implementing a behavior doesn't match RichEdit or Edit window classes on Windows. We should match either native edit window class. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 5:54 PM, Ryosuke Niwa rn...@webkit.org wrote: Having said that, I object to implementing a behavior doesn't match RichEdit or Edit window classes on Windows. We should match either native edit window class. Are you referring to my comments about the cursor? Do you object, then, to other behaviors the native controls don't support, e.g. triple-click to select all (not part of at least some versions of CRichEditCtrl, which is why I hand-implemented it in the Chrome omnibox)? In general, if we have a superior way of doing something, are we to be forced to avoid implementing it because Microsoft didn't get around to adding it to CRichEditCtrl? Let's argue about things like block-cursor-in-overtype-mode from a is it good for users perspective, not from a what does class XYZ that ships with Windows do perspective. That's the wrong priority. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 6:15 PM, Peter Kasting pkast...@google.com wrote: On Mon, Mar 11, 2013 at 5:54 PM, Ryosuke Niwa rn...@webkit.org wrote: Having said that, I object to implementing a behavior doesn't match RichEdit or Edit window classes on Windows. We should match either native edit window class. Are you referring to my comments about the cursor? Do you object, then, to other behaviors the native controls don't support, e.g. triple-click to select all (not part of at least some versions of CRichEditCtrl, which is why I hand-implemented it in the Chrome omnibox)? Yes, we should disable triple-click-to-select-all on Windows although there are certain features we would like to support (e.g. spell checking) for convenience and the Web compatibility. Granted, there are certain editing features that are hard to replicate native behavior (e.g. caret movements in bidirectional text) but those should still be considered as bugs. In general, if we have a superior way of doing something, are we to be forced to avoid implementing it because Microsoft didn't get around to adding it to CRichEditCtrl? The problem is that there is virtually no situation in which X is strictly superior to Y in all situations for any given X and Y. I remember I was stunned by how selection was painted in Google Chrome on Windows when it was initially released because it violated the platform convention I was used to on Windows. There were quite few other editing-related features that struck me as unconventional such as the caret appearing before the space following a word when moving caret forward at word boundaries. All those tiny differences added up to the point where I decided not to use Google Chrome as my primary Web browser on Windows. So I'm extremely skeptical when you say we can up with a superior way of doing something on Windows based on user expectations because user expectations are often shaped by other applications they use. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa rn...@webkit.org wrote: Yes, we should disable triple-click-to-select-all on Windows You realize that Wordpad, Word, and Internet Explorer all support this, though, right? My point was not just to raise a behavior that seems like a clear win, it was to reiterate that there's little connection between what a control does and what users will expect to see. Triple-click is widely used on Windows and taking it away would be clearly wrong from a user expectation perspective. Granted, there are certain editing features that are hard to replicate native behavior (e.g. caret movements in bidirectional text) but those should still be considered as bugs. There are also certain cases where the native control is just clearly buggy. For example,CRichEditCtrl draws bad selection highlights and adds an extra newline to the displayed string when used in single line mode, apparently because Microsoft never actually used it in single line mode and thus didn't test. There are other cases (which I forget) where certain actions just cause bizarre behavior that makes no sense and is clearly wrong. It makes no sense to me to replicate these sorts of things. I remember I was stunned by how selection was painted in Google Chrome on Windows when it was initially released because it violated the platform convention I was used to on Windows. There were quite few other editing-related features that struck me as unconventional such as the caret appearing before the space following a word when moving caret forward at word boundaries. All those tiny differences added up to the point where I decided not to use Google Chrome as my primary Web browser on Windows. Things like the caret movement were clearly wrong. Everything everywhere on Windows does caret movement a certain way and you're far from the only person who had problems with those sorts of things (I complained to Ojan about something like a hundred different such bugs). Even today there are still some lurking bugs when trying to expand the selection range on windows using shift+up or shift+down, and some other things that are obviously wrong. It's also worth noting that some behaviors cause usage issues and others don't. Getting the caret movement wrong, for example, causes concretely wrong output when someone attempts to rapidly edit text using the caret movement shortcuts they're familiar with. In the case of showing a blinking block cursor for overtype mode, not only is Windows inconsistent about how it handles things, but this purely visual change can't cause users to wind up with the wrong text. Indeed, the entire point is to point out that overtype mode is enabled -- which is not what the user intended 99% of the time anyway -- and help PREVENT incorrect output more quickly. So I'm extremely skeptical when you say we can up with a superior way of doing something on Windows based on user expectations because user expectations are often shaped by other applications they use. Thank you for reiterating my previous point: user expectations are shaped by how things actually behave, not what the underlying controls implement at a code level. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 8:32 PM, Peter Kasting pkast...@google.com wrote: I question whether it makes sense at all from a user's perspective. Users don't know or care what classes are used to implement their applications, they care what the applications do. And from that perspective Windows is all over the place. Wordpad, Word, and Visual Studio all support overtype mode, but all three do it differently (Visual Studio is IMO the best -- it actually changes the cursor from bar to block in overtype mode, which I'd love to see any other app supporting this to adopt, and certainly would want if we turned this on in Chrome for Windows). Notepad, which to almost any user who doesn't open files with LF line endings is the same thing as Wordpad, doesn't, and neither does Firefox or Chrome (today). Third-party editors are all over the place. I think we should decide this based on what is most helpful and least confusing to users. Normally a platform convention is a way of establishing what users will expect, which is why it has any value at all. Here I'm not convinced there's a user expectation of overtype mode in general, and I definitely worry that it has low utility and high annoyance, which make me greatly hesitate. And implementing it for rich text but not plain text on the web seems like a recipe for confusion too -- do normal users understand the distinction and would expect overtype mode in one but not the other? Seems more likely that some people would be frustrated that overtype mysteriously doesn't work sometimes, while others would be confused why every once in a while their text gets eaten, but not in a way they can reproduce consistently. I feel like I should give some background to this discussion. 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). 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. Regardless of whether WebKit will support overtype mode or not, our application will support it because our users expect it to. However, we want to keep the diff between upstream and our fork to be as small as possible. Also, to me it seems like we would be going against the principle of opensource software if we keep these features in our own private fork only, since it is something that can be useful to the general community. 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? Thanks, -shez- ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig shezbaig...@gmail.com wrote: I feel like I should give some background to this discussion. Thanks for this context. It's helpful. 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? Disclaimer: I'm not the gatekeeper of the WebKit codebase. Someone like Maciej might be a better judge of this. If none of the public WebKit ports intended to use the feature, I would say it doesn't belong upstream. Similarly, if some of the ports thought they might want to implement UI for this someday, but weren't presently doing so, I wouldn't upstream the core capability until at least one port actually begins implementing such UI. So perhaps the question is not so much would overtype mode be potentially interesting as are any public ports interested in exposing overtype mode to their users in the near term, and would dedicate someone to work on it. If yes, then upstreaming low-level hooks for this seems reasonable. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
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) 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 - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
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.comwrote: 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Overtype mode in WebKit for editable content?
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.comwrote: 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
Re: [webkit-dev] Overtype mode in WebKit for editable content?
On Mar 11, 2013, at 9:07 PM, Peter Kasting pkast...@google.com wrote: On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig shezbaig...@gmail.com wrote: I feel like I should give some background to this discussion. Thanks for this context. It's helpful. 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? Disclaimer: I'm not the gatekeeper of the WebKit codebase. Someone like Maciej might be a better judge of this. I'm not the gatekeeper of the WebKit codebase either! But in this specific case, I'd be inclined to ask experts on the editing code (such as Ryosuke and Enrica) whether they think it is a good idea and maintainable. It would also be useful to know whether any existing ports would want to expose overtype functionality. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
