Add SelectionChange event for content editable regions
Greetings all, I propose to implement selectionchange event, an event dispatched whenever selection changes. This event allows developers to be notified of selection change, and can be used to update status for RTE (e.g. toggling the appearance of bold button based on the context around caret). This event has already been implemented by Internet Explorer for document node<http://msdn.microsoft.com/en-us/library/ms536968(VS.85).aspx> . For example, if you do: document.addEventListener('selectionchange', function () {alert("selection changed!"), false); alert is shown whenever selection changes inside the current document. I'd like to make this event attachable to other elements as well so that developers can be notified of only relevant selection changes (target element is always document in MSIE's implementation). For example, we can easily extend this event to be fired from root editable elements because selection does not cross editing boundary. Alternatively, we can extend the existing select event to fire for root editable elements as supposed to fire only for input / textarea elements. For this alternative, see the note in the section 5.2.1. of the DOM Level 3 Events specification where it says: *Note:* The select<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-select> event may not be available for all elements in all languages. For example, in [ HTML5<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#references-HTML5> ], select<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-select> events may only be dispatched on only form input and textarea elements. Implementations may dispatch select<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-select> events in any context deemed appropriate, including text selections outside of form controls, or image or markup selections such as in SVG. Best regards, Ryosuke Niwa Software Engineer Google Inc.
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? 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. -- Darin
On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler <darin@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
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 <rniwa@webkit.org> wrote:
On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler <darin@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
participants (2)
-
Darin Adler
-
Ryosuke Niwa