Wedge

So... My test code is actually the label attribution code in PMs.

Interestingly, I've found out that you can enter this kind of thing for a label name:

<option value="rem_7"/>

Even more interestingly, because of the way it's all done (and, frankly, not very good security-wise), this will ACTUALLY be entered as a new option in the original select box.
Now... I don't really see a reason for this kind of 'hack' to be done by anyone, but do you think it's worth being concerned about...?
I'd rewritten the code to be shorter and use a string.match(...) instead of (x in toRemove) at some point. I changed my code to test for a longer string (starting with "<option" because the < sign is correctly html-entitified in the database), which I don't like, but should we go further and test for silly names..?

Also... What do you think of my method to avoid the FOUC on select boxes?
I like it, although it can be argued that if JavaScript is disabled, there's no way to see the select boxes at all.
But I'm also considering (again) the possibility of having jQuery and our scripts loaded ASAP, that is, asynchronously from the page header... I'm not exactly sure it'd be worth it, but anything that could help is welcome.

Thing is, it seems that the tech evolved since I began working on Wedge, so various async loading libraries have popped up in the last year, including Control.js which apparently would be the best, and has been forked by others, although I don't know which fork would be best. What I know, though, is that Control.js is 2KB gzipped and minified, and it's a bit much for my taste... I suppose I could be 'wrong', because after all, once it's loaded and cached, it's all good. I found another (jQl), made by a Frenchie, aiming to specifically async-load jQuery, so I like that, plus it's very short (700 bytes minified and gzipped after applying a few optimizations on it). I have yet to test it, though...

Anyway -- I like these ideas but I don't know if it's worth implementing all of this into Wedge. What do you think? (and it's probably not the best topic to ask about that so I'll probably move or split this post at some point...)

Well... Pretty quiet today innit?

After doing some tests with HeadJS (1.4kb minified and gzipped), it suddenly hit me... There's ANOTHER way of doing things!

It's not perfect, but here it is:

- While showing the head area, determine the *last login* time ($user_info['last_login']) and, if it's less than 10 minutes ago, assume that the user already has the script files cached in their browser cache.

- If cached, then run theme_base_js(1) right after theme_base_css() in the head.

- If cached, then at the end of the page, call $('select').sb() right after the inline JS has been printed (could even do that BEFORE any final JS really....), because the original call would have returned nothing at all (since the HTML was not printed out yet.)

- If not cached, then instead of the sb() call, simply show theme_base_js().

I tested it under Firefox 3.6 (my current testbed for Firefox, don't mind me), and the difference is very subtle, as in both cases it pretty much loads the select boxes immediately. It's done flawlessly in head mode though.

And of course, I also tested under Opera and while it still has issues showing select boxes immediately, it's much faster -- original had me wait for about one second on a typical page, while the new one takes about a tenth of a second. Only issue is that when I repeatedly reload the page (on my local install), the page stays entirely white for a few tenths of a second, and then it shows the page and almost immediately prints the new select box. I don't know which is best, honestly. I guess in a REGULAR situation (i.e. forum user), the second solution is better -- it probably loads (overall) a bit faster, but I guess it'll take a JS benchmark to make the difference.

Any opinions on this method?

Okay, considering how no one gives a damn about page optimization (does that mean I should reset my code..??), let's go back on topic...

I'm having some trouble with the onchange event on select boxes.
Basically, in a regular select box, the change event is triggered when you click a different entry in the list. Okay.
When it comes to keyboard navigation, it's more complicated... You focus on the select box (tab), press Space to open it (I don't know why it didn't work a few days ago...), you navigate with the keys, and you press Enter. ONLY when you press enter, will the display area be modified and the onchange event be triggered.
That is, if you (a) press SPACE to close the select box, or (b) press TAB to switch to another select box, the current selection is cancelled (i.e. not reflected in the display area), the list box is closed, and either gets the focus (space), or the next form element gets the focus (tab).

Now, if the select box is closed but focused, using arrow keys will navigate the list and fire an onchange event every time, which isn't great when said event tends to jump to a new page or whatever (because you then have no idea what you selected that resulted in this action), so I don't want to do that.

The 'solution' would be to rewrite the code to behave like a regular select box, and simply open the list box when navigating, i.e. never navigate without the list box opened. The only drawbacks are: (1) it takes more code (although at this point, it's not a big deal), and (2) when the onchange event would usually change the form's appearance, e.g. the custom field creator, where you switch between social media profiles like Facebook, if the select box is focused but not opened, pressing the down arrow key will immediately update the entire form with placeholders for these sites. Which, really, is pretty cool... But I'm not sure there's a point in that, except the fact that it looks cool.

Fishing for opinions...

:edit: Moved this topic to public... Not exactly sure why I created it in the private area.