Re: [whatwg] 'input' event interpretation
On Fri, 7 Nov 2008, Rimvydas wrote: Are you talking about section 4.2. The change and input events ? It still concentrates mostly on entering text with keyboard. But what another forms of input i've mentioned? They are still popular among UAs but are not mentioned here. However I think, as I've mentioned, they change the value of an input field due to input from the user (mouse click). My apologies, I meant in the HTML5 spec: http://www.whatwg.org/specs/web-apps/current-work/ There are various places that discuss 'input' and 'change', but in particular: http://www.whatwg.org/specs/web-apps/current-work/#common-event-behaviors -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 'input' event interpretation
Are you talking about section 4.2. The change and input events ? It still concentrates mostly on entering text with keyboard. But what another forms of input i've mentioned? They are still popular among UAs but are not mentioned here. However I think, as I've mentioned, they change the value of an input field due to input from the user (mouse click). 2008/11/7 Ian Hickson [EMAIL PROTECTED]: On Fri, 2 May 2008, Rimvydas wrote: The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. However, there are a few problems with current interpretation of this sentence. The first one - what is considered an input from the user? I just check on opera and firefox3 - they fire the event when I enter something, but if i select an entry from autocomplete list or browser fills some forms for me - it is not fired. When I select a value from a list I usually want the value in the field to change - it is like typing, just faster. I have filed a bug for ff. Maybe a specification could be more precise on what is an input from the user... I've tried to be clearer. Let me know if this is still ambiguous. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Rimvydas Naktinis
Re: [whatwg] 'input' event interpretation
On Fri, 2 May 2008, Rimvydas wrote: The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. However, there are a few problems with current interpretation of this sentence. The first one - what is considered an input from the user? I just check on opera and firefox3 - they fire the event when I enter something, but if i select an entry from autocomplete list or browser fills some forms for me - it is not fired. When I select a value from a list I usually want the value in the field to change - it is like typing, just faster. I have filed a bug for ff. Maybe a specification could be more precise on what is an input from the user... I've tried to be clearer. Let me know if this is still ambiguous. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 'input' event interpretation
Rimvydas wrote: The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. However, there are a few problems with current interpretation of this sentence. The first one - what is considered an input from the user? I just check on opera and firefox3 - they fire the event when I enter something, but if i select an entry from autocomplete list or browser fills some forms for me - it is not fired. When I select a value from a list I usually want the value in the field to change - it is like typing, just faster. I have filed a bug for ff. Maybe a specification could be more precise on what is an input from the user... Other problem is automatic form filling. Browser remembers some values (most frequently it is a login form) and when the page is loaded it enters them. Forms are also filled when in a login form user selects a name from an autocomplete list (the password is filled). In opera it is filled using 'wand'. The problem is - the values of fields change silently, without informing the page (i.e. without firing an event). Does specification say anything about this situation? If it does not, maybe it should? But in this case it would not be an input from the user so it should be a different event probably. Motivation. This would be convenient for various incremental search UIs and other cases when page should know about the change immediately. I agree. I think the fact that FF does not fire this event when forms are automatically changed one way or the other is simply due to bugs (most likely because the change is made using chrome javascript which makes it look like it's normal page javascript that changes the form). A clarification in the spec sounds like an excellent idea. / Jonas
[whatwg] 'input' event interpretation
The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. However, there are a few problems with current interpretation of this sentence. The first one - what is considered an input from the user? I just check on opera and firefox3 - they fire the event when I enter something, but if i select an entry from autocomplete list or browser fills some forms for me - it is not fired. When I select a value from a list I usually want the value in the field to change - it is like typing, just faster. I have filed a bug for ff. Maybe a specification could be more precise on what is an input from the user... Other problem is automatic form filling. Browser remembers some values (most frequently it is a login form) and when the page is loaded it enters them. Forms are also filled when in a login form user selects a name from an autocomplete list (the password is filled). In opera it is filled using 'wand'. The problem is - the values of fields change silently, without informing the page (i.e. without firing an event). Does specification say anything about this situation? If it does not, maybe it should? But in this case it would not be an input from the user so it should be a different event probably. Motivation. This would be convenient for various incremental search UIs and other cases when page should know about the change immediately. -- Rimvydas Naktinis
Re: [whatwg] 'input' event interpretation
On 5/2/08, Rimvydas [EMAIL PROTECTED] wrote: The question is related to the 'input' event on Web Forms 2.0. The WF2 specification says: This [input] event must be fired on a control whenever the value of the control changes due to input from the user, and is otherwise identical to the change event. It's supposed to fire with *any* user-initiated change you can think of. But, there can be a lot of ways to change a value, so it might take a while to support firing for every scenario. By change, that means to a *different* value. If you hit del in an empty textarea for example, the event shouldn't fire. If you want non-user-initiated changes by scripts etc., there's DOMControlValueChanged. Opera supports that I think, but it may not detect everything yet. There are still bugs in Firefox, Safari and Opera with input right now. I think you can only do oninput via addEventListener in Firefox (as opposed to .oninput= ). Opera fires the event twice for each change sometimes. Safari's input event support is broken right now. The spec should probably gives some examples of what's considered a user-initiated change: drag, cut, paste (with mouse or keyboard) etc. -- Michael
