A patch has been submitted to https://bugs.webkit.org/show_bug.cgi?id=45712.
- Ryosuke On Mon, Oct 11, 2010 at 6:21 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler <da...@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 > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
