Re: [webkit-dev] question about accessibility
There is ongoing work to implement the Web Speech API ( http://www.w3.org/community/speech-api/) in WebKit. Speech recognition works in Chromium, speech synthesis is mostly implemented on Mac OS X (but it's not enabled by default yet). In both cases, the actual runtime libraries aren't part of WebKit, they depend on the platform. - Dominic On Sun, Mar 10, 2013 at 1:46 AM, Ivano Arrighetta berserk82...@gmail.comwrote: hello everyone. I just wonder if webkit will include some runtime libraryes for accessibility like text to speech, ocr and speech recognition. this may sound silly, but there are many application examples of how this could be useful for accessibility. ___ 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
[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] Should we create an 8-bit path from the network stack to the parser?
Maciej, *I* deemed using a character type template for the HTMLTokenizer as being unwieldy. Given there was the existing SegmentedString input abstraction, it made logical sense to put the 8/16 bit coding there. If I would have moved the 8/16 logic into the tokenizer itself, we might have needed to do 8-16 up conversions when a SegmentedStrings had mixed bit-ness in the contained substrings. Even if that wasn't the case, the patch would have been far larger and likely include tricky code for escapes. As I got into the middle of the 8-bit strings, I realized that not only could I keep performance parity, but some of the techniques I came up with offered good performance improvement. The HTMLTokenizer ended up being one of those cases. This patch required a couple of reworks for performance reasons and garnered a lot of discussion from various parts of the webkit community. See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail. Ryosuke noted that this patch was responsible for a 24% improvement in the url-parser test in their bots (comment 47). My performance final results are in comment 43 and show between 1 and 9% progression on the various HTML parser tests. Adam, If you believe there is more work to be done in the HTMLTokenizer, file a bug and cc me. I'm interested in hearing your thoughts. - Michael On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote: In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. It would be good to find out who it was that said that (or more specifically: Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer.) so you can talk to them about it. Michael? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Spelling document markers: Design question
On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. What is contextual spellcheck? Contextual spellcheck in Chromium takes a sentence like The duck says quick and marks the word quick as contextually misspelled. The spellcheck would suggest quack instead of quick. Although all words are spelled correctly, the word quick makes less sense than quack in the context of that sentence. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? I'm with morrita on this one but it's hard to answer this kind of a design question without understanding what you're trying to achieve. What we're trying to achieve is provide a feedback loop for the spellcheck, so it can improve the suggestions over time. For the feedback loop to work, we're going to assign unique identifiers to spellcheck results and store the identifiers in markers. When the user performs any operation on a spellcheck marker, the identifier from the marker will be used in the feedback. User operations may include Add to dictionary, Always ignore, Select suggestion X, etc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Spelling document markers: Design question
On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita morr...@chromium.orgwrote: There are DocumentMarker, or DocumentMakerDetails. Which do you have in your mind? I had DocumentMarkerDetails in mind. It seems to be the standard location of auxiliary information for a document marker. Or you can possibly introduce another DocumentMakerDetails for the contextual marker. This approach might be cleaner. By introducing the new subclass, it won't interfere existing marker implementations. One caveat of this approach is that this needs extra heap allocations since DocumentMarkerDetails with unique IDs cannot be shared and will be allocated per marker. I like the approach with another DocumentMarkerDetails class. I would like to have both description and identifier in my DocumentMarkerDetails. Would it be OK to inherit from DocumentMarkerDescription? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] LLInt without JIT
Awesome, thanks for the detailed response. I did not realize that going to the assembly backend would not produce a substantial improvement. But after you explanation, I can see the reasons. I'll do some more testing to see the impact. If I see it to be worthwhile and I can fix it, I'll submit a patch, otherwise a bug. On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo fpi...@apple.com wrote: Yes. You can use the assembly LLInt backend without using the JIT. That's how I was running it when I first wrote it. I think that the code in Platform.h is being conservative, in the sense that it assumes that if ENABLE(JIT) is not set then you're compiling for a target that the LLInt wouldn't have a backend for. This makes sense, if you think about it: ENABLE_JIT is defined to 1 if we detect that we are on a hardware/OS configuration that the JIT knows how to handle, and the LLInt has backends for strictly fewer platforms than the JIT has backends for: JIT supports x86 (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and MIPS. In short, requiring the JIT to use LLInt assembly backends is not a strong requirement of the LLInt; it's just an artifact of Platform.h's logic. On hardware/OS configurations where ENABLE(JIT) is set, and the LLInt is compiled to assembly, it is still possible to run with the JIT disabled. The JIT ends up being disabled at run-time in that case. We often use this for testing - you can set the JSC_useJIT environment variable to 'false' and then you're running in a LLInt-only mode. This allows for quickly checking if a bug is due to the JITs, or not. But I would also note that the purpose of the LLInt assembly backends is _not_ performance of the LLInt itself, but for performance of the triple-tier system as a whole. What those assembly backends give us is the ability to run the LLInt using the same ABI that the JSC JITs use; this in turn allows us to do two things: (1) zero-cost OSR from the LLInt to the baseline JIT, and (2) perform every JS function call assuming opportunistically that the callee has been JITed; if it isn't then the machine code entrypoint that the callee reports is just the shared LLInt entrypoint. That entrypoint, in turn, doesn't really have to do anything special - it just loads the callee from the callee stack frame, loads the bytecode pointer from the callee, and indirect-jumps into the first bytecode instruction. We wouldn't be able to do either (1) or (2) easily with a C (or C++) interpreter. I mean, we could do it, but JIT-interpreter calls would be more expensive (because of the need to set up a C interpreter stack frame). And OSR would take more effort - it wouldn't be possible for the LLInt to just jump straight into JITed code like it does now. In summary, I don't expect the LLInt cloop backend to be any slower than the LLInt assembly backends. Last I checked, it wasn't slower. I would assume that a decent C compiler will take the LLInt cloop code and do sufficient optimizations that it ends up generating roughly the same assembly code that the LLInt assembly backends generate. So, I wouldn't devote too much effort to switching from the cloop to the assembly backends unless you had evidence that (a) it would actually be faster on the benchmarks you care about; or (b) you wanted to take advantage of the LLInt's ability to rapidly tier-up to one of the JSC JITs. It is because of (b), not (a), that JSC's triple tier configuration uses the LLInt assembly backends instead of cloop. But if you have reason to believe that the LLInt assembly backends will be better for your purposes then I think all it will take is hacking Platform.h appropriately. If this turns out to be hard, then you should file a bug, or even better, I would love to see a patch from you to improve the logic in Platform.h to make this use case easier. Hope this helps! -Filip On Mar 8, 2013, at 4:59 PM, Fritz Koenig frkoe...@google.com wrote: LowLevelInterpreter.asm is processed to create LLIntAssembly.h for the built platform. It appears that if there is no jitting configured[1], this will always create the C Loop. Is there any way of using the assembly backends to create LLIntAssembly.h when not jitting? [1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not available, enable the LLInt C Loop: */ ___ 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] Should we create an 8-bit path from the network stack to the parser?
Oh, Ok. I misunderstood your original message to say that the project as a whole had reached this conclusion, which certainly isn't the case, rather than that you personally had reached that conclusion. As for the long-term direction of the HTML parser, my guess is that the optimum design will be to deliver the network bytes to the parser directly on the parser thread. On the parser thread, we can merge charset decoding, input stream pre-processing, and tokenization to move directly from network bytes to CompactHTMLTokens. That approach removes a number of copies, 8-bit-to-16-bit, and 16-bit-to-8-bit conversions. Parsing directly into CompactHTMLTokens also means we won't have to do any copies or conversions at all for well-known strings (e.g., div and friends from HTMLNames). If you're about to reply complaining about the above, please save your complaints for another time. I realize that some parts of that design will be difficult or impossible to implement on some ports due to limitations on how then interact with their networking stack. In any case, I don't plan to implement that design anytime soon, and I'm sure we'll have plenty of time to discuss its merits in the future. Adam On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff msab...@apple.com wrote: Maciej, *I* deemed using a character type template for the HTMLTokenizer as being unwieldy. Given there was the existing SegmentedString input abstraction, it made logical sense to put the 8/16 bit coding there. If I would have moved the 8/16 logic into the tokenizer itself, we might have needed to do 8-16 up conversions when a SegmentedStrings had mixed bit-ness in the contained substrings. Even if that wasn't the case, the patch would have been far larger and likely include tricky code for escapes. As I got into the middle of the 8-bit strings, I realized that not only could I keep performance parity, but some of the techniques I came up with offered good performance improvement. The HTMLTokenizer ended up being one of those cases. This patch required a couple of reworks for performance reasons and garnered a lot of discussion from various parts of the webkit community. See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail. Ryosuke noted that this patch was responsible for a 24% improvement in the url-parser test in their bots (comment 47). My performance final results are in comment 43 and show between 1 and 9% progression on the various HTML parser tests. Adam, If you believe there is more work to be done in the HTMLTokenizer, file a bug and cc me. I'm interested in hearing your thoughts. - Michael On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote: In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. It would be good to find out who it was that said that (or more specifically: Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer.) so you can talk to them about it. Michael? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Mar 11, 2013, at 9:54 AM, Adam Barth aba...@webkit.org wrote: As for the long-term direction of the HTML parser, my guess is that the optimum design will be to deliver the network bytes to the parser directly on the parser thread. Sounds right to me. If you're about to reply complaining about the above, please save your complaints for another time. Huh? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
No complaints with the long term direction. I agree that it is a tall order to implement. - Michael On Mar 11, 2013, at 9:54 AM, Adam Barth aba...@webkit.org wrote: Oh, Ok. I misunderstood your original message to say that the project as a whole had reached this conclusion, which certainly isn't the case, rather than that you personally had reached that conclusion. As for the long-term direction of the HTML parser, my guess is that the optimum design will be to deliver the network bytes to the parser directly on the parser thread. On the parser thread, we can merge charset decoding, input stream pre-processing, and tokenization to move directly from network bytes to CompactHTMLTokens. That approach removes a number of copies, 8-bit-to-16-bit, and 16-bit-to-8-bit conversions. Parsing directly into CompactHTMLTokens also means we won't have to do any copies or conversions at all for well-known strings (e.g., div and friends from HTMLNames). If you're about to reply complaining about the above, please save your complaints for another time. I realize that some parts of that design will be difficult or impossible to implement on some ports due to limitations on how then interact with their networking stack. In any case, I don't plan to implement that design anytime soon, and I'm sure we'll have plenty of time to discuss its merits in the future. Adam On Mon, Mar 11, 2013 at 8:56 AM, Michael Saboff msab...@apple.com wrote: Maciej, *I* deemed using a character type template for the HTMLTokenizer as being unwieldy. Given there was the existing SegmentedString input abstraction, it made logical sense to put the 8/16 bit coding there. If I would have moved the 8/16 logic into the tokenizer itself, we might have needed to do 8-16 up conversions when a SegmentedStrings had mixed bit-ness in the contained substrings. Even if that wasn't the case, the patch would have been far larger and likely include tricky code for escapes. As I got into the middle of the 8-bit strings, I realized that not only could I keep performance parity, but some of the techniques I came up with offered good performance improvement. The HTMLTokenizer ended up being one of those cases. This patch required a couple of reworks for performance reasons and garnered a lot of discussion from various parts of the webkit community. See https://bugs.webkit.org/show_bug.cgi?id=90321 for the trail. Ryosuke noted that this patch was responsible for a 24% improvement in the url-parser test in their bots (comment 47). My performance final results are in comment 43 and show between 1 and 9% progression on the various HTML parser tests. Adam, If you believe there is more work to be done in the HTMLTokenizer, file a bug and cc me. I'm interested in hearing your thoughts. - Michael On Mar 9, 2013, at 4:24 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote: In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. It would be good to find out who it was that said that (or more specifically: Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer.) so you can talk to them about it. Michael? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Mon, Mar 11, 2013 at 9:56 AM, Darin Adler da...@apple.com wrote: On Mar 11, 2013, at 9:54 AM, Adam Barth aba...@webkit.org wrote: If you're about to reply complaining about the above, please save your complaints for another time. Huh? The last time we tried to talk about changing the design of the HTML parser on this mailing list, I got the third degree: https://lists.webkit.org/pipermail/webkit-dev/2013-January/023271.html I just wanted to be clear that I'm not proposing making those changes now and we'll have a chance to discuss the various pros and cons of each step as we consider making them. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Mar 9, 2013, at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 8, 2013, at 3:09 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Safari and DashboardClient (the executable that actually renders widgets) link the same copy of WebCore on disk, but are separate executables at runtime. Dashboard backwards compatibility mode is triggered by the per-WebView _setDashboardBehavior: call which then sets the usesDashboardBackwardCompatibilityMode setting. It appears that any app using this SPI either sets it on all WebViews or none I'm not sure that would be true for Dashcode. I could imagine that app setting Dashboard mode in its simulation views, but not in (say) a help viewing window. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Spelling document markers: Design question
Thanks for the clarification. On Mon, Mar 11, 2013 at 9:35 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. What is contextual spellcheck? Contextual spellcheck in Chromium takes a sentence like The duck says quick and marks the word quick as contextually misspelled. The spellcheck would suggest quack instead of quick. Although all words are spelled correctly, the word quick makes less sense than quack in the context of that sentence. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? I'm with morrita on this one but it's hard to answer this kind of a design question without understanding what you're trying to achieve. What we're trying to achieve is provide a feedback loop for the spellcheck, so it can improve the suggestions over time. For the feedback loop to work, we're going to assign unique identifiers to spellcheck results and store the identifiers in markers. When the user performs any operation on a spellcheck marker, the identifier from the marker will be used in the feedback. User operations may include Add to dictionary, Always ignore, Select suggestion X, etc. That sounds like a useful feature in general. On Mon, Mar 11, 2013 at 9:41 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita morr...@chromium.org wrote: There are DocumentMarker, or DocumentMakerDetails. Which do you have in your mind? I had DocumentMarkerDetails in mind. It seems to be the standard location of auxiliary information for a document marker. Or you can possibly introduce another DocumentMakerDetails for the contextual marker. This approach might be cleaner. By introducing the new subclass, it won't interfere existing marker implementations. One caveat of this approach is that this needs extra heap allocations since DocumentMarkerDetails with unique IDs cannot be shared and will be allocated per marker. I like the approach with another DocumentMarkerDetails class. I would like to have both description and identifier in my DocumentMarkerDetails. Would it be OK to inherit from DocumentMarkerDescription? I'd rather not add another subclass. That's even worse than modifying DocumentMarkerDetails IMO because this new subclass of DocumentMarkerDetails can't be shared among multiple markers. It seems okay for each DocumentMarker to directly have an identifier although we might want to if-def it depending on how big that identifier 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 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
[webkit-dev] Elliot Sprehn is now a reviewer
May our generated content (and general render safety and speed) live long and prosper. :) Grats Elliot! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Elliot Sprehn is now a reviewer
Congrats sir!! On Mon, Mar 11, 2013 at 3:46 PM, Eric Seidel e...@webkit.org wrote: May our generated content (and general render safety and speed) live long and prosper. :) Grats Elliot! ___ 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 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] Elliot Sprehn is now a reviewer
On Mon, Mar 11, 2013 at 3:46 PM, Eric Seidel e...@webkit.org wrote: May our generated content (and general render safety and speed) live long and prosper. :) Don't forget the Shadow DOM! Congrats Elliott! Ask Kling to get you the keys for the reviewers lounge. :DG ___ 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] Spelling document markers: Design question
On Tue, Mar 12, 2013 at 6:48 AM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the clarification. On Mon, Mar 11, 2013 at 9:35 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. What is contextual spellcheck? Contextual spellcheck in Chromium takes a sentence like The duck says quick and marks the word quick as contextually misspelled. The spellcheck would suggest quack instead of quick. Although all words are spelled correctly, the word quick makes less sense than quack in the context of that sentence. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? I'm with morrita on this one but it's hard to answer this kind of a design question without understanding what you're trying to achieve. What we're trying to achieve is provide a feedback loop for the spellcheck, so it can improve the suggestions over time. For the feedback loop to work, we're going to assign unique identifiers to spellcheck results and store the identifiers in markers. When the user performs any operation on a spellcheck marker, the identifier from the marker will be used in the feedback. User operations may include Add to dictionary, Always ignore, Select suggestion X, etc. That sounds like a useful feature in general. On Mon, Mar 11, 2013 at 9:41 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita morr...@chromium.org wrote: There are DocumentMarker, or DocumentMakerDetails. Which do you have in your mind? I had DocumentMarkerDetails in mind. It seems to be the standard location of auxiliary information for a document marker. Or you can possibly introduce another DocumentMakerDetails for the contextual marker. This approach might be cleaner. By introducing the new subclass, it won't interfere existing marker implementations. One caveat of this approach is that this needs extra heap allocations since DocumentMarkerDetails with unique IDs cannot be shared and will be allocated per marker. I like the approach with another DocumentMarkerDetails class. I would like to have both description and identifier in my DocumentMarkerDetails. Would it be OK to inherit from DocumentMarkerDescription? I'd rather not add another subclass. That's even worse than modifying DocumentMarkerDetails IMO because this new subclass of DocumentMarkerDetails can't be shared among multiple markers. It seems okay for each DocumentMarker to directly have an identifier although we might want to if-def it depending on how big that identifier is. On the other hand, if the ID is assigned per spellcheck request, not per word, it can be shared in the requested sentence. So the overhead won't that big. Also, API surface on DocumentMarkerController will be suffered by the change, especially if we ifdef it. Considering that the contextual spell checking (not grammatical checking) is virtually a chromium only feature, it might be better to let the complexity cost small by just extending DocumentMarkerDetails. I'm fine with either way though. There isn't big difference here. - R. Niwa ___ 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: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
