« Requiring JS in the admin panel
Selectbox
Some admin menu changes »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #30, on December 18th, 2011, 06:09 PM »
And I'm currently at... 2438.
Although the current implementation is buggy -- but less than before. The problem I'm dealing with, is that when an option is selected and I reopen the select box and use the keyboard to navigate through it (granted, it's not a 'common use case'...), the keyboard event will be fired twice, resulting in the list navigating down two items instead of one. And it will be fired one more time per close/open operation. Yeah, that does mean one of the events is NOT correctly deleted but for the love of Einstein I can't figure out why (I'm now down to just ONE keyboard event being set instead of 3 or 4...)

I'm sure I'll find out. And then I can finally commit all of my changes. :P
Re: Selectbox
« Reply #31, on December 18th, 2011, 09:21 PM »
Currently at 2390 and I'm on my way to fix the bug... :)

The original code was a real mess, come to think of it. It looks like several people worked on it separately and each added their own flavor of event handling... And, it's quite obvious they didn't test it extensively when hunting bugs.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #32, on December 18th, 2011, 09:27 PM »
Isn't that always the way though?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #33, on December 18th, 2011, 10:11 PM »
I guess so, but they could have been more careful...

Seriously, they hijack the keydown, keyup and keypress events when it could just be done once. They also hijack keydown twice... Just to cancel a few keys that don't seem to do anything for me anyway.

Okay, the 'culprit' for the bug is in $orig.focus(), which doesn't seem to work very well. Still haven't found a workaround though... :( :( :(

Also, I think I found a bug here...

Code: [Select]
// loses focus if original is blurred
.bind("blur.sb", function () {
if (!$sb.is(".open"))
blurSB();
});

This basically means... "If the original (hidden) select box is blurred (i.e. folded/closed), call blurSB() (it's a recent uncommitted rewrite -- originally it says something like "trigger the blur event for the displayed select box"). But it says, "only if the displayed box is NOT OPENED"... Which totally makes sense. So I removed that silly exclamation mark... And then, I removed everything because there's no way one could blur the original select, AFAIK... And I don't see why any of our scripts would trigger it, themselves. Saves more data. Currently at 2377.
Re: Selectbox
« Reply #34, on December 19th, 2011, 12:24 AM »
Best I could reach was 2372...
Back to 2400+ now, because after fixing the problem above, I found another problem... Pressing the Space bar while under a select box would show an empty select box next to ours (?!). I have no idea what this is about... Bullocks.
I'll deal with that tomorrow. I can prevent the space bar from working, but it still doesn't help when the select box is in an inactive state.
Re: Selectbox
« Reply #35, on December 19th, 2011, 12:39 PM »
I'd love to get some feedback on the latest commits... I think it's currently quite stable as it is.

One thing I did today, was download NVDA (an open-source screen reader) and try it on my select boxes. Unfortunately it didn't prove to be very useful... If you're closing your eyes, it sucks: once you get to it, it'll read out the label and then the various options... but if you navigate between options, it doesn't tell you which is which, and even if you select one, it doesn't confirm it. Add to that the fact that pressing Return will submit the entire form... I need to fix that one. But the rest... I'm surprised it doesn't work, given that there's 130 gzipped bytes of Aria processing in all this.
Anyone knows a bit about Aria and accessibility in general...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #36, on December 19th, 2011, 05:08 PM »
I know too little about ARIA in general, however what's the behaviour with normal selectboxes?

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #37, on December 19th, 2011, 06:50 PM »
Not fantastic either... But it does list the options as you're navigating them with the keyboard. Much more helpful...
Re: Selectbox
« Reply #38, on December 19th, 2011, 10:06 PM »
Quote from Nao on December 19th, 2011, 06:50 PM
Not fantastic either... But it does list the options as you're navigating them with the keyboard. Much more helpful...
Apart from that annoying issue (for which I'd love to find a solution.........), the current local implementation is actually behaving better than a default select box... :eheh:
Basically, I looked at how a default one worked with keyboard shortcuts, and decided which ones felt 'abnormal' and which felt 'natural' to me. I implemented the natural ones, and changed the behavior of the abnormal ones.
Only thing left to do is determine whether I should open the dropdown when pressing the arrow keys on a folded select box (after focusing it with the Tab key, obviously). Currently, the behavior is the same as the default: it navigates through the list, but with the dropdown not triggered. I think it'd be much better if the dropdown was opened automatically. In my version, hitting the Space key would open the dropdown (I couldn't find any key shortcut to do that on a default!), but it still feels a bit unnatural to me.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #39, on December 19th, 2011, 10:23 PM »
It's going to be unnatural, you're used to point and click, not keyboard navigation... Though I'll try and check it out as well if it's committed before Wednesday morning before I'm cast into purgatory (visiting the in-laws) for a week.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #40, on December 20th, 2011, 09:21 PM »
So... I've got this little thing going on with keyboard navigation, where the original code is completely broken, and my new code is a bit less broken, and my uncommitted code actually works, but I don't know if it's behaving the best possible way...

Basically, I could handle non-special keystrokes in two possible ways.

1/ I hit 'e' and the list is positioned to the first item with an 'e'. I hit 'e' again and it doesn't move until I hit another letter which redirects me to that one, etc. It's basically the default select box behavior I've always seen... Natural, but not very practical.

2/ I hit 'e' and the list is positioned to the first item with an 'e'. I hit 'e' again and it gets positioned to the next item starting with an 'e'. I hit 'e' again and it gets reset to the first item if there's no other 'e' in the list. It's the intended behavior in this selectbox plugin, apparently it is also the default selectbox behavior but I've never seen that happen... Also, the selectbox plugin simply doesn't do that at all.

3/ I hit 'e' and the list is positioned to the first item with an 'e', e.g. 'ebony'. I hit 'e' again and it gets positioned to the first item starting with an 'ee' (notice the two here), or anything AFTER 'ee', e.g. 'elephant'. I hit 'e' again and it stays there because at this point it's looking for 'eee' and there's nothing before 'elephant' anyway.

The 3rd case is probably less natural, BUT it pretty much behaves like a combobox, where you get an extra field that shows you what you've typed, as a 'hint', so basically:

4/ behave like a combo box, i.e. add a temp field somewhere that shows what you've typed, and allow the user to hit Backspace to go back one letter. Obviously, this one will take a bit more time to develop, and a bit more space in the final file... (It could possibly even take 500 extra bytes... Considering the time I spent on saving that extra 1.3KB from the original code, it'd be upsetting for me.) And for something which I'm not sure would be used by anyone at all.

So... Anyone has a favorite in the list?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #41, on December 20th, 2011, 09:54 PM »
The second case is actually my preference. I've yet to see a combobox work well when it's used for anything other than the actual original purpose for a combobox.[1]
 1. That is to say, if it's used to pick an item or provide space for a user to enter their own. It is after all, a combination text and select box, hence the name. The textual element is not designed to make selection easier, but for free format.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #42, on December 21st, 2011, 12:14 AM »
Okay, second case then!
Maybe I can use the extra space to add a scrollbar replacement plugin... :P

I looked into it, found one (here), about 1KB minified and gzipped, reduced to 600 bytes with my usual talent at crushing bytes (?!), it even supports touch events, unfortunately after all this work, I realized it required adding some shitty extra html like empty divs and such... (Yeah, I know, I can add these through JS too... I just don't think it's very neat to even do it that way. Really, the only redeeming feature is the small size :P)
Any™ opinions™?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #43, on December 21st, 2011, 11:35 AM »
*shrug* If the extra divs are added through the plugin, run with it. I think it adds serious branding and consistency potential to use custom scrollbars.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #44, on December 21st, 2011, 08:30 PM »
Oh, well... I'll have to give up on that for now. I spent most of the day trying to tie the scrollbar into the select box, and it just won't cooperate.

I think... I think the CSS for the select box might need a rewrite first. And something is telling me that I'll break the stuff, and then go back to what it was, and give up altogether on the custom scrollbar...
Even if it's only 600 bytes, it's 600 high-maintenance bytes, a bit like my super-menu code...
« Requiring JS in the admin panel
Some admin menu changes »