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
