Re: events on user setting text direction

Well, scripts can remember the last text value and dir value that they saw
and by comparing determine what it is that has happened. It is not that bad.
The main thing is to be notified that something has happened. But I think of
this as mostly a windmill. As far as I know, oninput, despite being
implemented by all minus IE, is not part of any standard, least of all the
HTML spec. I tend to doubt that this particular request will be granted.

Aharon

On Tue, Sep 28, 2010 at 1:38 AM, Ehsan Akhgari <ehsan@mozilla.com> wrote:

>  On Mon, Sep 27, 2010 at 3:37 PM, Aharon (Vladimir) Lanin <
> aharon@google.com> wrote:
>
>> At the face-to-face, we said:
>>
>> > (Section 3.8)
>> >
>> > 28. There is no need to trigger the oninput event
>> > when the user explicitly sets the direction of an
>>  > <input> or <textarea> element since the dir
>> > attribute change that this causes should generate
>> > the DOM2 DOMAttrModified event
>>
>> It turns out that this is not exactly true. WebKit currently does not
>> support DOMAttrModified and it is unclear if they ever will. Firefox,
>> apparently, supports it, but only triggers it when an attribute is changed
>> by script, not by the browser UI (as would be the case for setting text
>> direction). And finally, DOM3 deprecates all the mutation events,
>> including DOMAttrModified. They are supposedly working on an alternative,
>> but we have no idea whether it will actually come to be or if it will apply
>> to our case. Thus, I am leaving the original suggestion to trigger the
>> oninput event when the user explicitly sets the direction.
>>
>
> Given the concerns you mentioned here (well, all except for the first
> one!), I think that's a good choice.  There is one point though, how are web
> page scripts supposed to determine whether the input event has been raised
> because of direction change or because of actual input?  Should we use a
> property on the event object?
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>