[webkit-dev] webkit editing rewrite?

[Darin Adler]

On Aug 3, 2010, at 4:32 PM, Ojan Vafai wrote:

> Pros:
> -Ensures that the APIs we expose to the web are at least good enough for our own editing code
> -Ensures that editing code never crashes (outside of JSC/V8 bugs)
> -Gives a clean slate for starting the editing code anew
> -Moves code out of WebCore
> -If other browser vendors choose to expose the same APIs, then we can share the editing library and make the world better for web developers
> 
> Cons:
> -Potentially slower since DOM calls are now JS-->C++
> -Potential for regressions due to holes in the layout test coverage
> -Not statically typed

I am more interested in what these new APIs would be that we’d rebuild editing on top of. Using JavaScript as the programming language doesn’t seem so great, but I’m not as passionate about this as I am about devising good abstractions to build editing on top of.

Coming up with the abstraction that lets us build efficient editing code seems like a challenge. Programming language has little to do with it. We’ve had lots of performance problems with editing code.

Inventing a new layer to rebuild editing on top could well be good. Exposing that layer itself to webpages seems like it makes the job even harder rather than easier! Hidden implementation details can be changed more easily than exposed APIs.

I personally don’t think a complete rewrite is a great idea, nor do I think that using JavaScript is how I’d do it.

    -- Darin