<div>A patch has been submitted to†<a href="https://bugs.webkit.org/show_bug.cgi?id=45712">https://bugs.webkit.org/show_bug.cgi?id=45712</a>.</div><div><br></div><div>- Ryosuke</div><div><br></div><div>On Mon, Oct 11, 2010 at 6:21 PM, Ryosuke Niwa <span dir="ltr">&lt;<a href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>&gt;</span> wrote:</div>

<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler <span dir="ltr">&lt;<a href="mailto:darin@apple.com" target="_blank">darin@apple.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



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





</blockquote><div><br></div></div><div>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&#39;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.</div>

<div class="im">



<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote>





<div><br></div></div><div>Agreed.</div><div><br></div><div>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?</div>


<div><br></div><div>- Ryosuke</div><div>†</div></div>
</blockquote></div><br>