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