[webkit-dev] Editing Meeting

[Ryosuke Niwa]

 On Tue, Apr 13, 2010 at 2:35 PM, Ojan Vafai <ojan at chromium.org> wrote:

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

But does that mean web authors need to manually set these CSS styles to
achieve what they want?  IMHO alinging WebKit's behavior with that of
Firefox / MSIE will be a better long-term goal unless it's unfeasible.  Or
is this feature targeted towards very specific apps?

Perhaps, we might want to discuss with other folks in whatwg to see if we
can standarize this behavior first.  Because we probably don't want to get
in a position where we implemented this new feature, and then HTML5 decides
to do something else that forces us to undo everything.  Or yet worse,
different UAs can't agree on one spec and we provide web developers with yet
another source of headache.


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

I agree that asymptonic behavior is important.  I recall some selection
tests are very slow, and I love to investigate on that.  However, we
probably need to refactor editing commands more since there are many
mutually recursive editing commands right now, and they're making it hard to
analyze the time complexity of each command.


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

I like the idea of getting rid of node/offset pairs but how do those four
node correspond to the existing node/offset or Position / VisiblePosition?

Best,
Ryosuke Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100413/5bac1197/attachment.html>