[webkit-dev] webkit editing rewrite?

[Ojan Vafai]

At the editing meeting at the WebKit conference in April, we discussed the
idea of coming up with a replacement to Position/Range, using that
throughout the editing code and then eventually exposing that API to the web
to supersede DOM Ranges. Specifically, the idea was to get rid of
node/offset pairs and instead having the following possible positions:
beforeNode, nodeStart, afterNode, nodeEnd. We would then only use offsets
for positions inside text nodes.

There are also a slew of other APIs web developers need to make editing work
well, e.g., undo management, better selection control, position normalizing,
etc.

Finally, the editing code is crashtastic. Some of that is due to less than
great foundations like the current Position class. Some of it is due to
editing just being complicated.

Some of us had a somewhat crazy idea to rewrite much of the editing code
(e.g. document.execCommand) in JavaScript.

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'm not too concerned about the perf hit. It should be no more than a
constant-factor and, historically, the editing perf problems have been
order-of-magnitude issues.

As for the functionality regressions, I think they're inevitable. We'd hit
most of the same issues trying to refactor the existing C++ code on top of
better APIs. The best we can hope for is to write extra tests for each bit
that we port over. We don't need to do this as one large atomic swap. We can
port one command at a time over to keep this as incremental changes.

There's also the question of whether we should expose the library code to
JS. But that's orthogonal really. I think we shouldn't to start with not
exposing the code. We can always decide to expose it later if we think it's
worthwhile.

What do you think?

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100803/46821150/attachment.html>