[webkit-dev] Add SelectionChange event for content editable regions

[Ryosuke Niwa]

On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler <darin at apple.com> wrote:

> It seems that if our aim is to be compatible with the IE event, we should
> make our implementation as close to the IE one as possible. I’m not sure
> that firing the same event, but with a different target, will be good for
> compatibility. Is there some chance this could lead to a webpage that works
> in IE but fails in our engine, that would have worked fine if we used a
> different event name?
>

The goal is to provide developers a way to detect selection change.  The
idea was that if we had multiple editable regions, developers often want to
know which of those editable regions have the selection.  Of course, they
could walk the DOM upwards from the current selection to find the editable
root but I can't think of cases where developers want to receive the
document node as the target (maybe useful if we had multiple iframes with
design mode on?) because they almost always have the access to the document
node.

I think that firing the same select event for editable areas in the document
> as for input and textarea elements might be a mistake, because the functions
> for querying and working with the selection are not uniform for those
> elements. Inside the engine we treat these much the same, but in the DOM API
> they are quite different.


Agreed.

Alex pointed out that it might be better to have an extra event property
(e.g. webkitEditableRoot) that points to the editable root or other element
and make target always point to the document node for compatibility.  Do you
like this design better?

- Ryosuke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101011/bddbca22/attachment.html>