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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
34 matches
Mail list logo
