[webkit-dev] Editing Meeting

[Roland Steiner]

I have to say I agree with Ryosuke that this requires more consideration
(see inline comments).

On Wed, Apr 14, 2010 at 6:35 AM, Ojan Vafai <ojan at chromium.org> wrote:

> 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
>

There are 2 main issues I see with this approach:

   - User style sheets can be crafted to inadvertently or deliberately break
   web apps that rely on a specific setting


   - It creates rather many ambiguous cases, and some cases are impossible,
   e.g. with nested elements of the same type: ... <span class="a"><span
   class="a"> ... </span></span> ... --> how can I "wrap" the inner span, but
   not the outer (e.g., to delete it)?


In general I'm not sure this is a good invariant to keep (even though I can
understand the desire for it). E.g., on the boundaries of, say, bold and
non-bold text I find it most intuitive that I continue typing bold if the
cursor came from the bold side (i.e., is still within the <b> element), and
type non-bold if the cursor came from the non-bold side (i.e., is outside
the <b> element). Implementing such doesn't seem possible with this scheme.

As mentioned in another post to webkit-dev, I'd rather prefer having the
ability to specify arbitrary (non-normalized!) ranges that are affected by
editing operations. E.g., adding a 4th optional parameter to execCommand:

    execCommand(command, showUI, value, range): if the 4th parameter is
present it specifies the range the command operates on. Otherwise the
default is the current selection.

This would be straightforward (IMHO), non-ambiguous and also remove the
current necessity of futzing around with the selection state. Also,
technically this isn't mutually exclusive with the CSS-based proposal (and
adding such attributes may still be worthwhile to guide user-made
selections), but it obviates the need to rely on it.

Now this would probably require more up-front standardization discussions
compared to a vendor-specific CSS attribute, but being more generally useful
(IMHO) I'd expect it to be less controversial in the end (may well be wrong
here, of course).


- 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).
>

Yes, that's a great idea!


 - 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.
>

This is quite similar to my refactoring proposal I sent to the mailing list,
so I'd very much like to see this change and would be glad to implement/help
implementing it!

Just for clarification how this is meant:

   1. does this also remove the current "virtual" positions such as [<img>,
   1], i.e., beginningOfNode(node) == beforeNode(node.firstChild),
   endOfNode(node) == afterNode(node.lastChild) if a child exists, and
   beginningOfNode(node) == endOfNode(node) if the node is empty and there is
   no beforeNode/afterNode in such a case, OR
   2. this retains the current "virtual" positions, and beforeNode/afterNode
   are for such positions (e.g., [<img>, 0] and [<img>, 1]) and
   beginningOfNode/endOfNode are for "regular" positions (or vice versa)

I'd very much hope for 1.) here... ;)


Cheers,

- Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100414/63727996/attachment.html>