[webkit-help] Fwd: Problem extending WebViewUndoableEditing
alexander.shulgin at yessoftware.com
Wed Aug 25 06:03:10 PDT 2010
On 21.08.2010 21:04, Ryosuke Niwa wrote:
> On Sat, Aug 21, 2010 at 8:10 AM, Alexander Shulgin
> <alexander.shulgin at yessoftware.com
> <mailto:alexander.shulgin at yessoftware.com>> wrote:
> For content editing capabilities we've found that WebKit behavior is
> often surprising or plain broken. So we've patched it (on Windows)
> to accept our custom editing commands through newly introduced COM
> interface. Now, if we design the commands carefully we can enjoy
> arbitrary editing capabilities and undo/redo operations work smoothly.
> I'm sorry about that :( Could you mind listing problems you had with
> our behavior so that we can fix them in the future?
Our biggest concern is paragraphs merging. We use
replaceSelectionWithNode method in quite a few places and far too often
we get unsatisfactory results: while the look of rendered HTML might be
well expected, the HTML text itself is ridden with gigantic <span
Another problem we're constantly struggling with is visual cursor
position. Inserting content at cursor was all but what expected until
we've implemented that ourselves. For example, pasting text right
before <h1> would go under the heading tag and/or introduce a span with
style imitating h1 look...
As I understand these quirks come from the initial application of
content editing: mail composer. Typical user doesn't care about
internal HTML representation of the letter as long as it looks nicely
and as expected. But unfortunately, this behavior is unacceptable for
I also think there is unlikely to be a silver bullet fixing these
problems, as we find we need different workarounds for different editing
actions using the same replace-selection/insert-at-cursor commands.
> I think I can, but that would be no different from my current
> approach. And this will just complicate things further w/o the real
> need for it.
> Trying to sketch this move of CustomEditingCommand to WebCore I see
> the strong need for some proxy object (or three separate ``functor
> objects'') to be passed from WebKit to WebCore:
> Right, the proxy is required but I don't think it's a minus because
> EditCommand::* are really meant to be used inside WebCore.
> What you
> really should be doing is to make your editing commands inherit from
> CompositeEditCommmand and use simple commands to do your work because
> I'm sure things like splitElement and removeNodePreservingChildren are
> useful in any implementation of editing. That way, you don't have to
> manually save & restore states in each of your editing command.
Oh I would do that with great pleasure only if I could. I have to
mention that again: our custom commands are in C# realm and from WebCore
point of view they all are just SimpleEditCommands with
apply/unapply/reapply triplet of primitives.
> But if you're saying that you've implemented a better
> SimpleEditCommand's or found a better way of implementing editing
> commands, I'm very interested in knowing what you did because we can
> take the same approach in WebCore itself.
Unfortunately, not--we didn't any significantly better. We're using the
same concept of simple and composite commands, only we don't need to
recompile WebKit to fix every single problem in editing commands.
So basically, we (ab)use this new possibility to re-implement parts of
WebKit the way we like it w/o the need to dig deeply into its internals.
More information about the webkit-help