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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
