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

[Ryosuke Niwa]

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  wrote:

> On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler  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

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

[Ryosuke Niwa]

On Mon, Oct 11, 2010 at 11:34 AM, Darin Adler  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

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

[Darin Adler]

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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Ryosuke Niwa]

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
.

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
event
may not be available for all elements in all languages. For example, in [
HTML5
], 
select
events
may only be dispatched on only form input and textarea elements.
Implementations may dispatch
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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev