On 21.08.2010 21:04, Ryosuke Niwa wrote:
On Sat, Aug 21, 2010 at 8:10 AM, Alexander Shulgin
<[email protected]
<mailto:[email protected]>> 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
style="-list-of-almost-all-possible-css-properties-">.
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
our application.
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.
--
Alex
_______________________________________________
webkit-help mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-help
