[web] The magic of the form controls in Firefox
Author
As well as being a pain in the rear to use as a in Firefox itself (text wrapping is erratic in large text fields, slow, random text highlighting to name a few) the dropdown boxes are really starting to annoy me. [grin]
A standard Windows combo box will allow you set the focus. Firefox does this. If you scroll up and down with your mousewheel, a Windows control will scroll, whereas the ones in Firefox don't. I assumed this was because you had to expand the combo box then click on a new one to set it. However, this isn't the case - if in focus the mousewheel does nothing, but the cursor keys can change the box. Fine, you might ask - where is this leading up to? Well, I am using a combo box as a selection box for a user. When you select the user, a bunch of information is displayed next to the box. This is done with some JavaScript which is fired off by the onchange event of the combo box. Firefox, however, completely fails to generate an onchange event if you change the combo box with the cursor keys. Is this a known quirk? Or does IE let it work as expected "by accident"? Or should I not be using the onchange event, in favour of one which works?
I had that same problem.
I had to catch the onkeyup (or onkeydown) event of the combobox, and check if the selected index had changed.
It's stupid, but I think it's the only reasonable way to tackle this problem.
I had to catch the onkeyup (or onkeydown) event of the combobox, and check if the selected index had changed.
It's stupid, but I think it's the only reasonable way to tackle this problem.
Author
Oh well. Thanks - it's just calling a single function, no arguments, so it's not too tricky to implement. The oddly behaving form elements in FF are one of the reasons I don't use it that frequently...
Author
Yes, I have. Hope it gets fixed...
EDIT: No, it won't get fixed. They claim it's the "correct" behaviour.
[Edited by - benryves on March 30, 2005 10:01:40 AM]
EDIT: No, it won't get fixed. They claim it's the "correct" behaviour.
[Edited by - benryves on March 30, 2005 10:01:40 AM]
The basic problem is, that Microsoft got the wheel wrong.
The wheel, as you'll think if you look at it, is attached to the mouse. It's physically connected - nay - even built-in. A non-detachable part.
This is clear to any reasonable person.
What is also clear, is that the buttons are attached to the mouse, and the mouse controls a little arrow thingy.
Now, if you look at the behaviour of the other button, you'll notice, that when you press them, they always affect the element where the pointer resides.
This seems good and logical.
Then, if you're a windows user, you'll notice that despite being firmly attached - integrated in fact - to the mouse, the wheel behaves totally differently - in fact, it behaves more like it were attached to the KEYBOARD.
Yes - that's right - the wheel is actually on the KEYBOARD in Windows!!!?? What madness is this?
It's totally nuts. Whoever thought it up was funny in the head. The wheel is on the mouse. It's not connected directly to the keyboard at all.
However, it seems true - Microsoft do seem to think the mouse wheel is a part of the keyboard. The element which it usually affects, is the one which has the *keyboard* focus. Not where the pointer is. No. That would be too obvious. That would be too consistent with the other thingies on the mouse (notably the buttons).
---
Microsoft have got most things in the UI right. The one thing that they've got VERY wrong, is that the wheel behaves like it's attached to the keyboard.
Use X on Linux and you'll see what I mean. Here I can scroll the element where the pointer is, using the wheel. It doesn't affect the keyboard focus, and it's not affected by it.
However I would question Firefox's choice to ignore the platform's arguably insane standard.
Mark
The wheel, as you'll think if you look at it, is attached to the mouse. It's physically connected - nay - even built-in. A non-detachable part.
This is clear to any reasonable person.
What is also clear, is that the buttons are attached to the mouse, and the mouse controls a little arrow thingy.
Now, if you look at the behaviour of the other button, you'll notice, that when you press them, they always affect the element where the pointer resides.
This seems good and logical.
Then, if you're a windows user, you'll notice that despite being firmly attached - integrated in fact - to the mouse, the wheel behaves totally differently - in fact, it behaves more like it were attached to the KEYBOARD.
Yes - that's right - the wheel is actually on the KEYBOARD in Windows!!!?? What madness is this?
It's totally nuts. Whoever thought it up was funny in the head. The wheel is on the mouse. It's not connected directly to the keyboard at all.
However, it seems true - Microsoft do seem to think the mouse wheel is a part of the keyboard. The element which it usually affects, is the one which has the *keyboard* focus. Not where the pointer is. No. That would be too obvious. That would be too consistent with the other thingies on the mouse (notably the buttons).
---
Microsoft have got most things in the UI right. The one thing that they've got VERY wrong, is that the wheel behaves like it's attached to the keyboard.
Use X on Linux and you'll see what I mean. Here I can scroll the element where the pointer is, using the wheel. It doesn't affect the keyboard focus, and it's not affected by it.
However I would question Firefox's choice to ignore the platform's arguably insane standard.
Mark
Author
Quote:Original post by markr
However I would question Firefox's choice to ignore the platform's arguably insane standard.
That's not the real problem, really. It's that it doesn't fire the onchange if you change the dropdown with your keyboard. As for focus, you can move the keyboard focus around with the mouse by middle-clicking on something then scrolling (just middle clicking without scrolling starts autoscroll) (usually).
But yes, I quite agree - the mouse wheel does some very annoying things!
I think the onchange event is only supposed to be fired once the keyboard focus leaves an element - this is certainly its behaviour with text input items etc.
It doesn't get fired the instant that something changes.
Mark
It doesn't get fired the instant that something changes.
Mark
http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange
"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus."
Basically, if IE is sending an onchange for each keypress, it's doing it wrongly. So yeah, you should really be using one of the keypress events instead.
"The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus."
Basically, if IE is sending an onchange for each keypress, it's doing it wrongly. So yeah, you should really be using one of the keypress events instead.
I'm strongly against the 'onchange' event being used to trigger events, unless it's something simple like disabling / enabling controls.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
