[webkit-dev] Editing Meeting

[Ojan Vafai]

On Tue, Apr 13, 2010 at 11:13 AM, Eric Seidel <eric at webkit.org> wrote:

> - There is an issue where application does not behave as expected:
> <a>....</a> depending on the position of the caret into the tag, the
> behaviour is not the same.
>

The more general point here is that web apps need control over where editing
commands go (e.g. where text gets inserted or where Range.insertNode inserts
the node). The common case is anchor tags, but there are apps with custom
widgets (e.g. comments in Google Docs) that need different behavior. The way
they do this in Firefox is to control where the selection is (e.g. set it to
be inside/outside the anchor). This doesn't work in WebKit because we
normalize to a VisiblePosition.

Up to now, we've been assuming that the solution is to add the same support
as Firefox. The suggestion at this meeting was to instead approach this from
a policy perspective since we don't want web apps to have to capture
key/mouse events to make this work. That way, we keep the invariant that
there is one VisiblePosition to each cursor position. So, instead, we'll
propose adding CSS rules that control this.

-webkit-selection-affinity-start: inside/outside
-webkit-selection-affinity-end: inside/outside

start/end refers to the affinity at the start/end of the node. I don't
particularly like the word "affinity", but I can't think of anything better
at the moment.

Eventually, once we implement this, we can put this in html4.css and get rid
of all the code that assumes the current affinity.

There's a few edge cases where we need to make arbitrary decisions:

   - <b>foo</b><span>bar</span>: If the b and span elements both have inside
   set, then one of them needs to win. I'll suggest the one that comes later in
   the DOM.
   - <span><b>foo</b></span>: If b is set to inside and span is set to
   outside. The element deeper in the DOM should win.
   - <b></b>: If start and end are set on an empty element, then start wins.

High-level and/or detailed criticisms are welcome.


> - We talked about creating performance tests for the various DOM
> operations.
>

The specific idea was that we care more about order of magnitude runtime
than we do raw numbers. So we can do something much simpler than proper perf
tests that require a reference build. Instead, we can have tests for
specific actions with different values of n to make sure that an O(n) case
doesn't become O(n^2).


> - We talked about deprecating "position" class, and getting rid of
> node, node offset pairs in the DOM.
>

We'd like to remove node/offset pairs entirely from
VisiblePosition/Position. Instead we'll have beforeNode, afterNode,
beginningOfNode, endOfNode. The only exception is that we'll still need
offsets for offsets into text nodes.

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