-
A short note...
Yesterday I was looking into improving the privacy selectbox, notably to allow for friend groups to be specified, was planning to turn it into an object similar to the privacy button on Wedge.org (click the key icon next to a topic link (that you own, in a blog), and it opens up a popup, select Groups or something and it'll show you a checkbox list...), then I found out about selectbox replacement plugins for jQuery, looked into their code and demos, I particularly liked one (it basically creates an absolutely positioned div with scroll overflow like the key object in here, but does it while retaining compatibility with non-JS browsers so that'd be nice to use everywhere), anyway -- when packed and gzipped, the main script file is 5.89KB, and with the extra plugin (which I would clearly modify...), it's 8.52KB. So that's an increase of 50% in size, but OTOH it's still less than 3KB... And then on the other, other hand, 3KB is exactly the reason I'm not excited to upgrade jQuery to a newer version... :lol:
I'm not sure just yet.
The demo: http://labs.abeautifulsite.net/projects/js/jquery/selectBox/
Second time this week I'm on this website... I have no idea why I was there the first time, I just remember I liked their logo... And now I'm starting to realize my own logo for Wedge may have been unconsciously influenced by them :lol: No, no, it's just leaves... :^^;:
-
See, the whole nature of doing that would never have occurred to me. I'd have just used a regular select.
Mind you, if that's styleable (e.g. to put an image next to the item text)... I can think of many good uses for that.
-
Membergroup legend is a bit of an unimportant area for me, so whatever...
BTW, I'm starting to seriously consider, between two casual dragon kills, going with my own custom selectbox component... Something that would be simpler or more complex than the one I saw, depending on the point of view.
The idea would be to, perhaps, reuse some of the minimenu code, maybe entirely, maybe merge them etc, and make the Wedge design as uncluttered as possible by having most options moved either to a minimenu (i.e. opens when hovering), or a selectbox (i.e. opens when clicking the option or the arrow next to it), or an arrowbox (or whatever I'd call that... i.e. opens when clicking the arrow next to the option, and goes to the option when clicking it. Sort of thing that would work well in Wedge button strips.)
-
As long as there's a non JS fallback and there aren't overwhelming accessibility issues (e.g. speech readers, or dare I suggest it, keyboard users, aren't adversely impacted), I'm cool with that.
As for membergroup legend, I'm strongly considering pulling it out into a plugin where I can give it more options and merge some of the existing plugins around it.
-
BTW, I'm starting to seriously consider, between two casual dragon kills, going with my own custom selectbox component
$(document).ready(function(){
$('select.pf_select').each(function(){
var title = $(this).attr('title');
var id = $(this).attr('id');
if( $('option:selected', this).val() != '' ) title = $('option:selected',this).text();
$(this)
.css({'display': 'none'})
.after('<ul class="smalltext menu"><li id="' + id + '_li"><h4><a>' + title + '</a></h4><ul id="' + id + '_ul" style="visibility: visible; border-radius: 0; opacity: 1; display: none;"></ul></li></ul>')
.change(function(){
val = $('option:selected',this).text();
$(this).next().text(val);
})
.children('option').each(function() {
if ($(this).text() == '-')
$('#' + id + '_ul').append('<li class="separator"><a><hr></a></li>');
else
$('#' + id + '_ul').append('<li id="' + $(this).val() + '"><a>' + $(this).text() + '</a></li>')
});
$('#' + id + '_li').click(function(event){
$('#' + id + '_ul').show();
});
$(document).mousedown(function(event){
$('#' + id + '_ul').hide();
});
$('#' + id + '_ul').children('li').each(function () {
$(this)
.bind('mouseenter focus mouseleave blur', function(event){
$(this).toggleClass('hove');
})
.mousedown(function(event){
$(this).parent().children('li').each(function () {
$(this).removeClass('active');
});
$(this).addClass('active');
$('#' + id).val($(this).attr('id'));
});
});
});
});
-
Had a look. It's funny how you reused the main menu styles! I made it a bit shorter and it was already quite short. Needs more features but it seems to be a good start thanks.
-
Had a look. It's funny how you reused the main menu styles! I made it a bit shorter and it was already quite short. Needs more features but it seems to be a good start thanks.
-
Had a look. It's funny how you reused the main menu styles! I made it a bit shorter and it was already quite short. Needs more features but it seems to be a good start thanks.
However, while the main menu css is fine for short select boxes, how about a select box with hundreds of items? It will definitely require a scrollbar... And for this, the main menu doesn't have a ready-made answer. That would require dropping the rounded corners, to begin with.
-
The code I posted already disables rounded corners
-
Yup, noticed that.
Okay, I'm posting my version of the code... It's not particularly better or anything, it just matches the coding guidelines for Wedge.
However I probably won't be using it as is in the future. I'm still considering options, like taking a larger library and reducing its size, etc.
function we_selectbox()
{
var that = $(this), id = that.attr('id'), title = $('option:selected', this).val() != '' ? $('option:selected', this).text() : that.attr('title');
that
.hide()
.after('<ul class="menu"><li id="' + id + '_li"><h4 class="hove"><a>' + title + '</a></h4><ul id="' + id + '_ul" style="visibility:visible;border-radius:0;opacity:1;display:none"></ul></li></ul>')
.change(function () { $(this).next().text($('option:selected', this).text()); })
.children('option').each(function () {
var here = $(this), txt = here.text();
$('#' + id + '_ul').append(txt == '-' ? '<li class="separator"><a><hr></a></li>' : '<li id="' + here.val() + '"><a>' + txt + '</a></li>');
});
$('#' + id + '_li').click(function () { $('#' + id + '_ul').show(); });
$(document).mousedown(function () { $('#' + id + '_ul').hide(); });
$('#' + id + '_ul').children('li').each(function () {
$(this)
.bind('mouseenter focus mouseleave blur', function () { $(this).toggleClass('hove'); })
.mousedown(function () {
$(this).parent().children('li').removeClass('active');
$(this).addClass('active');
$('#' + id).val($(this).attr('id'));
});
});
};
$('select').each(we_selectbox);
-
First things first.
I'm looking into the JumpTo object and I still don't get why it has the ability to show multiple boxes.
I mean, it's only used in two places in SMF and Wedge: Display, and MessageIndex. And in both cases -- only one per page.
Removing the related code removes a few bytes off each topic page (not a bad thing I'd say), and also removes about 20 bytes from the gzipped minified script file. I'm really, really not against that...
Can anyone think of any reason to keep the array of JumpTo objects...?
Right now, the only thing I could think of is turning the moderation selectbox into a jumpto, which isn't the case right now. I mean, you click 'Move to' and then it enables the selectbox next to it... But it's already filled in. I don't really see the point in having a JumpTo object if admins and moderators always have to load the complete board list on every page just for a feature they won't be using 99.9% of the time... :-/
Other than that, I'm still looking about select boxes and stuff...
I want to have the 'right' component for Wedge. Something between the lightness and simplicity of John's implementation, and the richness of jQuery plugins.
The main problem here is with accessibility, as per Pete's request (and mine, honestly.) The 'light' code doesn't allow for keyboard accessibility, for instance.
So, here are the 'few good ones'... They all support 'disabled', optgroups and such. And they're all MIT licensed or equivalent. Also, I haven't done a complete test case for all of these, so the pro/con list is incomplete. I'm just trying to sort it out myself and maybe some of you will be aware of a better selectbox component for Wedge..?
As a reminder: once this is settled, I'm planning to use select boxes in many places, including places where we don't currently have a select box. The only difference with a mini-menu is really the fact that it opens once you click the item...
http://labs.abeautifulsite.net/jquery-selectBox/
Pro: also does listboxes. Excellent keyboard accessibility.
Con: minified/gzipped size ~3000 bytes, position is fixed so if the parent div moves, this won't.
http://www.bulgaria-web-developers.com/projects/javascript/selectbox/
Pro: gzipped/minified size is ~2000 bytes
Con: keyboard accessibility is average at best. Doesn't close the box when clicking elsewhere (can be remedied easily I suppose...)
http://dl.dropbox.com/u/124192/websites/selectbox/index.html
Pro: Has clear support for HTML elements inside select boxes (I want that and will add it to whatever I use in the end). Allows to set small width for select line and large width for select box (i.e. they aren't linked), and does multi-line entries like I wanted, too. Also, keyboard accessibility is good...
Con: ...although it has a strange habit of closing the box when keeping the arrow keys pressed -- if you just press them, it'll switch to the next item all right, but if you keep the key pressed, once it triggers the message to 'repeat' the keystrokes automatically, the box closes. Doesn't handle right clicks on items and selecting text inside items (all of these should be disabled IMHO -- but I think none of the competition does that either.) Also, the size is the worst, at about ~3700 bytes gzipped and minified.
http://code.google.com/p/sexy-combo/
Pro: does a combo box...! It's pretty neat being able to type in what you want, and it'll automatically open the related elements in the list so that you can click them.
Con: size is ~4700 bytes so... Yikes!! And there isn't a demo available. But you can see a demo of UFD by following the link in the sidebar. It uses jQuery UI thought, so it's not something I'll be using...
Posted: November 14th, 2011, 04:32 PM
Bump.
-
The first seems a good compromise between size and accessibility. I should mention I wrote that script I posted above because I want something like selectmenu without the UI hulk.
-
As a note. None of the above has flawless support for iOS. Heck possibly the only one to work the same way is the smallest one...
-
The criteria for me in order is: working correctly, having a suitable fallback position for keyboard/accessibility cases, looking nice, size.
Seems like most of the above have issues with the first two.
-
Pete, luv ya but you're not helpin' much :P
The third is my current fave still but it fails to sync disabled states between it's own ui and the iOS ui. It's strange. Although we don't really use disabled states anyway.
Also the ui for iOS needs a HTML to text fallback.
In any case these will all require a rewrite. That's why I only choose MIT stuff.
What about jumpto?
-
Pete, luv ya but you're not helpin' much
The third is my current fave still but it fails to sync disabled states between it's own ui and the iOS ui. It's strange.
Although we don't really use disabled states anyway.
Also the ui for iOS needs a HTML to text fallback.
In any case these will all require a rewrite. That's why I only choose MIT stuff.
-
Also, sidebar behaviour still not great on iPad. Haven't tried in portrait yet but can't imagine it would be much different.
The sidebar collapses to the left side as expected but the only way to trigger it being visible is to tap in the area where the thought edit option is, which forces it to be visible, and it doesn't perform any auto collapse after.
-
Even the latest rev?!
-
That's based on whatever's on the demo site as of earlier today, which IIRC has 1164 on it? (Which is for all intents and purposes, is the latest rev.)
-
Okay, I've split all posts related to select boxes, merged them into a single topic...
I've found a new one, in additions to the ones listed on page 1, that I think is particularly awesome:
http://harvesthq.github.com/chosen/
I don't know the gzipped size (will have to test), but it's 5.5KB when minified and zipped.
The big plus is that when you multi-select something, you see all items listed in a pretty neat way -- just have a look at the demo. It could inspire us, if only for the auto-suggest item...
Here are the things we need in a select box, I'd say:
- perfect accessibility fallbacks
- ability to have wide options while having a set width on the select box itself
- ability to show comments (like a dfn) below options -- I'm thinking we could put them inside HTML comments, and have the widget retrieve them and show them below the options when you open the select box. Also, we could show these comments next to the select box when it's updated with a new option.
- HTML elements in options
- would be nice to have a combo box...
- would be nice to have a script below 5KB when gzipped and minified.
- automatically update contents when changing the select
- automatically moving the HTML box when changing select box position
Also, I'd like us to discuss privacy settings (this is the thing that prompted me to change the select box in the first place.)
Are the privacy settings at Noisen/Wedge.org enough, would you reckon?
Is it needed/useful to have membergroups in the list?
Should we allow better granularity of friend access?
How do you suggest we store privacy in the database? As a bit-wise variable? A list of numbers? Or more?
Posted: November 28th, 2011, 06:02 PM
Please give your opinion on the intended feature lost, too.
-
Bump on the above... :whistle:
So, now that I'm done with mismatched tags, I'm trying to get back into the select box stuff.
Decided to try for jquery.sb.js for now, and try to optimize the size (since it's really the only thing I have against it.)
Pete, you remember the discussion we had on the oddities of gzipping? Well, it's back in full force...
something = function (event, params) { otherthing.call(event, params); };
So... I figured out that params was never used, so I removed both params calls.
As a result, the gzipped file is 5 bytes larger. Ah ah.
Now... I have plenty of if (...) { one_instruction(); } in the code. I removed the curly braces. As a result, the more braces I remove, the LARGER the gzipped file becomes.
Okay, so I figured, if it's crazy enough to do things like that, let's tag along and add a preg_replace to add curly braces to all single-line tests...
And guess what? It's the exact same size as before it was modified. I looked into it a bit more, and there's just TWO cases where removing the curly braces will make the file bigger, while in other situations it'll usually save a byte.
Anyway, I'm pretty much done and saved about 350 bytes off the original ~3700 bytes. It's not fantastic, but at least it's getting closer to the other selectboxes, and with the extra features.
Now it's going to be realllllly funny when I actually try to run the plugin on Wedge... Yeah, I didn't even try :P
Posted: December 12th, 2011, 01:51 PM
And... it works :)
-
Interestingly but not really that surprising.
Let me explain the reason why it works. The Deflate algorithm doesn't work on single characters but repeating character strings; I'd imagine for example that 'if (' is one such string it notes and inserts a reference for. By putting in extra { and }, you elevate them from single characters that typically don't make much in the way of repeating patterns at the byte level, into something that *explicitly will* be a repeating pattern.
I'm not sufficiently au fait with the LZ77 and LZ78 algorithms and Huffman encoding that underpin Deflate but there's the base cause, that you're giving it a pattern to match rather than individual characters that will be largely just added verbatim in the stream.
-
As I said, I do remember our conversation :P
I simply tried to apply that philosophy to the code and it simply didn't make any sense... Obviously after seeing the param stuff, I looked for other similar functions and didn't find any. Even better -- $(this).each(...) isn't needed, you can simply do this.each(...) in prototypes, but it also adds more bytes... So I went ahead and changed all of the $(this).each() to this.each(), still the same, then I simply went through all $(this) and this, and there were far more this than $(this), actually if I simply used (this) instead of $(this), I'd end up with the same filesize as with $(this)... It would only go up when doing this with nothing else. That's really... funny, in a kind of way.
Anyway, it's only a few bytes so I'm just not going to bother either way...
The best way to save space is to removed dead functions and things like that. There were quite a few in this plugin!
Psychologically, one of my goals is to have the main javascript file under 10KB when zipped. With the original code, it was just a bit over 10KB. Now it sits comfortably under 10KB and I guess I can optimize script.js itself in more ways, too ;)
-
but it also adds more bytes...
-
This one's funny, too...
(packed version)
var b,e,h,b=c(this);
Realized my mistake, turned it into this...
var e,h,b=c(this);
And voilà! 3 extra bytes to the filesize, ah ah...
-
...weird. Compression is a harsh mistress.
-
Removed another 100 bytes... I'm starting to consider removing options we don't/won't need. For instance -- support for TIE. It's a plugin that will check the DOM for changes and report them to sb so that it can update the selectbox. However, I'd rather have full control over this and simply trigger sb's update process myself whenever I do changes to the select box... What do you think?
Also has some options like 'displayFormat' which allows you to customize the display... Only, it's not like we're releasing a selectbox plugin... We're simply using it in Wedge. I don't see any reasons to change the HTML outside of the (modified) plugin itself. Do you?
-
I don't see any reasons to change the HTML outside of the (modified) plugin itself. Do you?
However, I'd rather have full control over this and simply trigger sb's update process myself whenever I do changes to the select box... What do you think?
-
Well, it's not like sb's source code is gonna disappear overnight anyway... There's plenty of code in it that's too "general" for my taste. For instance, it includes a library called jQuery-Proto that adds some nifty features to JS "classes". That's all good, but it also adds plenty of options that, ahem, aren't used by the SB object at all... So I simply deleted them all, restarted, and it still works... And is much lighter.
Now we're about at 3150 bytes, so that's over 500 bytes less than when I got started. I hope I can actually remove even more...
-
Now we're about at 3150 bytes, so that's over 500 bytes less than when I got started. I hope I can actually remove even more...
-
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
-
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.
-
Isn't that always the way though?
-
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...
// 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.
-
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.
-
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...?
-
I know too little about ARIA in general, however what's the behaviour with normal selectboxes?
-
Not fantastic either... But it does list the options as you're navigating them with the keyboard. Much more helpful...
-
Not fantastic either... But it does list the options as you're navigating them with the keyboard. Much more helpful...
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.
-
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.
-
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?
-
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.
-
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(http://baijs.nl/tinyscrollbar/)), 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™?
-
*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.
-
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...
-
For some unknown reason, doing a $sb.remove() on the select box doesn't work in Opera 11 and 12... It isn't removed.
Went as far as debugging jQuery, and elem.parentNode.removeChild(elem) is executed -- no error, and nothing removed!
Grmpf......
-
I'm pirating my in-laws' wifi on my iPod Eheh.
I think maybe I'll rewrite the refresh code to only delete the unordered list. Repopulate it. That way it'd work but it'd take more js obviously. I dunno why this happens. Can anyone test the svn version?
-
Sorry, test what of the refresher?
-
Try doing $(..).sb('refresh') on a click. Does it remove the item or duplicate it?
-
Looks like the whole thing is duplicated
-
Found the reason... $orig.removeData("sb"), very bad idea when the element is never set at all in loadSB... :P
Still, it remains a bit buggy even after deleting that... :-/ In my particular test case where I'm doing complex manipulations at least.
Posted: December 25th, 2011, 11:43 AM
Problem is indeed fixed, but the area I was testing is a bit fragile. Hmm... It's annoying when SMF uses complicated code they don't comment... :P
-
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..?
-
There is no reason to consider that, if only because it shouldn't occur, and if it's being done, it'll misbehave whatever happens anyway.
-
Why does selectMatchingItem specifically look at the first letter? Don't the regular select boxes search the whole text?
-
I don't think so? I think opera only goes for first letters. How would you do it otherwise?
-
You're right, they only do the first letter. So much for assuming something works one way when it really doesn't.
-
Unfortunately it means that if all entries have a prefix then it won't work well. Like "--->" you know. Unless I add a data-prefix entry to have the code skip it...
-
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...
Posted: December 29th, 2011, 06:24 PM
:edit: Moved this topic to public... Not exactly sure why I created it in the private area.
-
Worst nightmare in months... Every time I fix a bug in this, it creates a new one. Frankly, if I didn't know better, I'd just come to the conclusion that I suck at JavaScript!
It isn't the case -- it's just that it's a fucked up concept. The main issue is with event transmission. I've looked into other plugins and they all have strange ways to deal with these -- and they're not very good at dealing with internal modifications like adding an option dynamically, etc.
Anyway, I just wanted to post that, next time I want to implement a library that "seems easy enough to do", someone should tell me to give up immediately because it's gonna bite my in the ass... :lol:
-
Just for 'fun'... Here's what I'm having trouble with.
User clicks select box "Label selected" in PM area. This triggers a "focus" event, loadLabelChoices(). Which fills in the select box with the proper values.
That's the theory... Now, in practice:
- if I fill the select box again, then I need to refresh the Wedge version of it... So at the end of the function, I'll call the refresh function.
- said refresh function will call .focus() on the original.
- which triggers loadLabelChoices, which triggers the refresh, etc...
It's not exactly an infinite loop because I've added protections, but this is enough to screw up the process.
I've been on this for two days... Trying to find a 'proper' way to launch a refresh without having to say, "okay guys, we don't want you to focus the original... Okay?". Found many techniques, each time it fails somewhere.
Now, the funny thing is that Wedge only has TWO FREAKING select boxes in the entire codebase that bother with the focus event... (This one, and the JumpTo.) And both of these will actually never make use of the focus accessibility feature, because as soon as you click an option, it goes to another page...
I'm just posting to... well, make sure that it's on a record. Select boxes suck!!
-
What about the one on the who's online page?
-
I don't think it's generated on focus. Can't check though. Not on my pc.
Btw some bugs I had in Firefox 3 don't show up in later versions. Ahah. Good fun. I'll use v8 for the rest then.
-
Okay, to answer the post above -- the Who's online page reacts on change(), not focus(), so it's definitely not an issue.
BTW... It's been over 24 hours since the last post was sent here. I think we broke a record or something... :P
-
Okay, an alternative to the odd code seen in rev 1233 would be to simply not care about onfocus, and ask modders to use onclick instead...
The difference is simple. onfocus triggers when you activate a select box (in 99% of cases, that means when you click it.) onclick triggers when you click the select box (as it opens the dropdown.)
So, basically, the ONLY difference is that onclick is never run when you use the keyboard to navigate.
I figured, I *could* possibly fire a click event when opening the select box via the keyboard... What do you think?
That way, the infinite loop thingy is no longer possible. (As long as no one uses onfocus, of course!)
I wrote a small piece of code that would watch for DOM changes to any select box and call reloadSB as needed, but (1) it adds about 200 bytes of code to the whole thing, (2) it's a hack, (3) it adds more issues that I can't bother to fix right now. So I'm adding it to our wip folder instead... (Because it's still quite cool.)
-
Any reasons I'm the only one who posted in the last 48 hours...?
Am I that boring?
Technical issues?
-
Well, yesterday was New Year's Day ...
Speaking for myself, January is a crazy month in terms of deadlines and exams. Priorities, heh ...
-
Well, yesterday was New Year's Day ...
It's just that I kept seeing people in the Who's Online list, but no one would post... Even those who made it a habit to post their opinions on many different subjects. :-/
-
So... It's 8PM, I've been on this since 8AM...
Trying to fix onclick events. Breaks onfocus events. Then the other way around. Then all works... But not when using keyboard. Fixing this. Breaks onclick. Fixing. Breaks onfocus. Fixing... Breaks mouse events.
OH MY...
Select boxes are developer hell. I just checked out Kyodai Mahjongg and since I'd rewritten the entire UI to use textures, obviously I'd made my own select box for it... (Used in the high scores window.) Well, it works. Only it doesn't have all of these silly events to deal with... :^^;:
I don't know where to start (or finish)... And again, I'm tempted to call it quits.
-
So... It turned out that many of my issues with events here (namely, them not triggering when expected), was due not to the order in which events are executed -- but simply, to the fact that the original events were only copied on the first call (with a pretty smart single-line statement). Fact is, that single line only works *before* the page has finished loading. After that, it's useless. So I wrote a longer version, and also used the opportunity to retrieve all non-jQuery events, making it possible to add events to select boxes through .html("<select onclick...>") rather than assigning them any .bind() events after creation.
Meh... It's messy.
And of course it didn't work in IE8. (At first.)
I think I've had my share of SHITTY code that keeps sending me bugs whatever I do. I always beat them in the end. This one is no different, I'll beat it just the same. Problem is just that -- WHEN the hell does this happen?!
I've been on this for THREE WEEKS. Fantastic. And it's far from being finished! I still need to write that scrollbar code. And check every single <select> in Wedge. (All direct <select> manipulations are done, but I have no idea where it has some silly hidden code like $('<select id=something>') then $('#something').append()... (This is why I'd rather always use clearer code.)
-
Aaaand I think I'm going to give up on these event imports as well...
Probably just going to import .click events, I guess. Because let's be honest, it's the only kind of event we have in Wedge, AND it's not like I'm trying to make a universal select box. Modders can adapt. If I want to go universal, I'll rewrite it again anyway...
-
Well... Good news: it only took me a day to implement the custom scrollbar... :eheh:
It has its limitations, of course. But not that many, compared to the small size (~700 bytes of minified/gzipped JS + about 90 bytes of minified/gzipped CSS for now.)
And it has a few bugs left... But the main code is done, phew.
-
You have done very, very well with this :)
-
Thanks :)
And good to have you back!
I'm still not sure about the scrollbar thing... I actually made the script.js optimizations (rev 1237) in order to compensate for the extra bytes added by it. But it's still not enough IMHO. Also -- script remains quite buggy... I'll have to delve deeper into it. It's spectacularly broken right now, I don't know when/where I screwed it up.
-
Hmm, I shouldn't have tested my select box on IE... :P
Fixed a few bugs in IE6 today, but some remain.
- If select box has a scrollbar, in IE7 there's extra padding added to the left of the box items... A gap of exactly 16 pixels. I set margin and padding to 0 and list-style to none, it does remove the discs but doesn't change the margin... I don't think I SHOULD use negative margins, should I...?
- As mentioned in the latest changelog, if you move the thumb and release your mouse button when outside the select box, it will close in IE 6-9, as opposed to other browsers. For this one, it's even more complicated... I believe it's due to IE not firing the events correctly, or not taking into account a click's stopPropagation in a parent's mouseup event or something. Anyway, others browsers run it... So, I changed the click event to a mousedown event -- and it suddenly started working! Yay... However, now when I click a box item to select it, the HTML elements around the select box will be selected, even though I do return false at the end of the mousedown event, which SHOULD normally cancel anything that comes after that (mouseup, click...), as well as prevent the default (this is where it seems not to be working.)
Obviously, Opera doesn't show this behavior. Haven't tested in other browsers.
I suppose no one has any idea how to come to terms with this..? And if it can't be fixed -- which is best? HTML selection after an item click, or select box getting closed after dragging the scrollbar thumb?
-
If you click and drag and go outside the element, deselect it.
Half the battle is simply because a selectbox normally operates outside the classical rendering (all its rendering is *totally* self contained and not accessible to the JS), I don't suppose it'd be any better operating as an iframe-type shim, would it?
-
I should specify that the selection bug only happens when trying to 'drag' the text (copy it) at the moment you click it (which is unlikely to happen..?), while the 'select box closing itself' bug happens everytime your cursor ends up outside of the box.
Also, the selection bug can be 'reproduced' by simply trying to drag smileys in the smiley list (basically, LOTS of areas can reproduce the bug..), and it only happens in IE.
iframes? Over my dead body...!
(My only fear is that Wedge somehow has an obscure area where select boxes are manipulated dynamically in a way that they can't be found by doing a regex search on your project files. Then again -- if nobody uses said feature, it won't matter, and if someone does, they're bound to tell us what we should fix...)
-
Why not then attach:
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
-o-user-select: none;
user-select: none;
That would prevent it being selectable in a way that just munging the events won't.
The iframe suggestion was out of left field, and I didn't expect it to be taken seriously :P
The only dynamic select box I can think of is the jumpto, I can't think of a selectbox that's populated dynamically anywhere else in the source.
-
As I said, the issue only happens with IE (6/7/8, not 9), so even the -ms prefix would be useless because only IE10 supports it. I could use the unselectable property, but even then I don't want to complicate things.
There are two dynamic select boxes that I know of: the JumpTo, and the PM global label selector -- it takes a list of available labels, determines which selected PMs already have it, and recreates the "Add label" and "Remove label" entries accordingly. I rewrote the code to simplify it -- now it generates two optgroups, so it helps with readability, but obviously it still repopulates the box. I could have the box contain every single entry and then simply 'hide' them which would make it easier to re-create, but there's no point in doing that. And yes, if I implemented some kinds of tricks, I could get away with removing at least 200 bytes of code (possibly a bit more) from the select box, but I don't want to impair any plugins by forcing them to do tricks when it's so elegantly handled by my code.
Anyway, that's irrelevant to the issue at hand...
When I say 'dynamically', I really mind the simple fact of doing manipulations on select boxes without referring to them as select boxes.
<select id="hello">
<option id="world" value="">Test</option>
</select>
Consider this:
$('select option[val=""]').val('Nyan nyan');
And this:
$('#world]').val('Nyan nyan');
They will both do the same thing... However, the second one forces me to go through every single select box in the code, take note of their IDs and their option IDs, and then go through the entire code again to search for possible manipulations. The point is, because SMF didn't use jQuery, and I didn't convert every single JS statement inside templates themselves, it's easier to do getElementById() on an option than going through getElementByTagName or something...
The problem is unlikely to happen in any non-admin pages, but the admin area... Some of its code is so convoluted... :-/
-
(BTW, IE problem fixed half an hour ago. I'm telling you just in case you'd want to look into it. Should have posted earlier...)
-
You did a freakin great job BTW :o
-
The admin area generally is a mess. Why do you think I wanted to torch it to the ground and start over?
-
Yeah eheh.
Lorenzo, you haven't even seen the completed select box on the demo site ;)
I shall update it soon though... But I'm currently hooked on Steins;Gate. Great show for 'realistic time travel' fans. :)
-
Could be worse, I've been hooked on playing with a 20 year old paint program that has features I've yet to see anywhere else (since I've been playing with pixel art for making canvas-based games)
-
Lorenzo, you haven't even seen the completed select box on the demo site ;)
It would be nice if in the footer of the demo site there was specified the "rev" that runs. Something like "Wedge rev 1242". :)
-
Hmm yeah I guess it's technically possible but it'd have to be done manually or we'd have to learn about svn a bit more. I remember looking into it...
Pete: Neochrome? deluxe Paint? Degas Elite? :P
-
Whatever script pulls the files can just edit the version string... I don't think there's any more elegant way of doing that without reinstalling.
Oh, and Deluxe Paint on the Amiga :D
-
Whatever script pulls the files can just edit the version string... I don't think there's any more elegant way of doing that without reinstalling.
Oh, and Deluxe Paint on the Amiga :D
DEMO UPDATED TO 1242!
Posted: January 8th, 2012, 05:15 PM
BTW -- quickest way to see the awesomeness of the select box in action: menu > PM > Send message.
Just play with the three select boxes in the post/pm editor. They're HTML, two of them have a scrollbar (with the small hover effect), and it just works flawlessly. :)
-
changelog.txt's first line, SMF?
-
DEMO UPDATED TO 1242!
Posted: January 8th, 2012, 05:15 PM
BTW -- quickest way to see the awesomeness of the select box in action: menu > PM > Send message.
Just play with the three select boxes in the post/pm editor. They're HTML, two of them have a scrollbar (with the small hover effect), and it just works flawlessly. :)
The only "glitch" I noticed is for the "Quick access" scrollbar. It lags 1 second the first time you click on it, then it's ok as the others. :-/
-
The only "glitch" I noticed is for the "Quick access" scrollbar.
-
Uhm.. and if it retrieved all the boards at page load? So it wouldn't "lag" when you click the scrollbar. Yes this will add some bytes to be loaded but I don't think that will be much..
-
It will add some bytes and an entire query *every single page*. Considering the frequency that goes with usage of the quick access/jumpto, it's really not worth the processing overhead every single page for it.
-
Uhm yes you're probably right.
-
If it were used far, far more (like every other page or so by every other user or so) then it might be worth it but as it stands, it's probably not worth it. Even going through the whole cache thing isn't really worth it, IMHO.
-
changelog.txt's first line, SMF?
(Ahh... Good times.)
Demo updated to rev 1243!
Regarding the Quick Access, yes, I for one wouldn't fill it directly with the board data. I actually think that we should even use that for the quick mod select box, where the board list is filled in at page generation time --- grrrrr.
Just have a look at Noisen... It has dozens of boards, if not hundreds (I don't think it shows boards that are created but not filled.)
Now imagine loading that list on every single board page... :-/
It's 'doable', especially with today's bandwidth availabilities, but it's still a waste.
-
In which case their SVN server does some magic in the post_commit hook. One of the perks of hosting your own SVN at least.
There's no hook for on-checkout or on-update, the hooks are things triggered by a commit, either pre-commit or post-commit, and unless you fancy the core code having the SVN rev in it and milestone/release builds handled manually (compared to the actual core, e.g. actually manually or at least through some kind of script) there's no good way to deal with it.
Re the board listing, I wouldn't have a problem making the quick moderation adhere to that. In fact, I've been wondering about whether that needs changing; the fact that so many people ask where it went makes me think we should make it on by default - or even making it the *only* option, so if you can't moderate, you don't see it at all but if you can, that's the only view you get.
-
In which case their SVN server does some magic in the post_commit hook. One of the perks of hosting your own SVN at least.
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.htmlRe the board listing, I wouldn't have a problem making the quick moderation adhere to that. In fact, I've been wondering about whether that needs changing; the fact that so many people ask where it went makes me think we should make it on by default - or even making it the *only* option, so if you can't moderate, you don't see it at all but if you can, that's the only view you get.
Wanna do it?
And for the jumpto on this field? You or me? Can add to my to-do (although it's a bit crowded...), as you like.
-
Hmm, did they introduce that into the core software somewhere so that it would be added to index.php and shown in the footer, or was that only on their dev server for daily builds? I can't remember now.
Agreed...
Wanna do it?
And for the jumpto on this field? You or me? Can add to my to-do (although it's a bit crowded...), as you like.
-
Hmm, did they introduce that into the core software somewhere so that it would be added to index.php and shown in the footer, or was that only on their dev server for daily builds? I can't remember now.
There's two things here? I think jumpto should be extended to that field too, I just don't know when it'll be done :/ I really need to get back into the swing of PHP dev, spent a lot of the last few weeks doing all sorts of nice non-PHP dev.
Oh, here's what I was working on tonight... Was trying to find some kind of solution to make the userbox column into a nice monolithic thing without modifying the current HTML structure. Here's the result...
Is it worth exploring? Maybe not for Wine, but for one of the other stock skins..?
PS: right-click image and choose to view/open it, otherwise you won't see the bit that matters :P
PPS: we really, REALLY need to remove these icons in the userbox... They're pointless now, at least for JS users.
(http://wedge.org/amusing.png)
-
Wow that looks nice :D
-
The overall screenshot or the effect I asked about? :P
-
Bump for messages above... (?)
In other news.
Looked into many Wedge pages, and it turns out, many select boxes are broken by the new code... Yay.
For instance, if I hide a select box only to have it show up later (e.g. board list in quick mod on MessageIndex), it'll fill in the entire width of the container and be generally buggy.
Also, similarly, if you select a quick mod option, the select box will enlarge... Meh, an obvious bug.
My, why didn't anyone see that one? I always assume that people tend to test my stuff when I upload them on the demo site. Will I have to check every single select box in the entire codebase then...?
The only good news today is that I've found an extra couple of tricks to reduce the size -- it's now at 2577, down from 2669 which I already considered to be as short as it could be...
-
On the demo site,
I Started a new p-message and in the "To" box I typed "bil".
"Billy2" dropped down as expected, I selected Billy2.
The "To" box remained as "bil" even though I selected "Billy2" and wouldnt obviously send as "bil" as it was not a user account.
It seems the same for a couple of other users I tried.
-
Oh, thanks -- bug added by a rewrite last week.
Posted: January 10th, 2012, 01:16 PM
Actually, it's older than that... I don't even know why I remember it working these last few months...?!
It's going to be a heavier rewrite. I could go back to the original SMF code, but it's pretty ugly really...
-
Most people here can't see the quick moderation selectbox, even if it were enabled by default because it only shows up if you have moderation privileges.
-
Shouldn't we enable it by default? I thought it was...
-
Most people here can't see the quick moderation selectbox, even if it were enabled by default because it only shows up if you have moderation privileges.
-
Yes, we should make it that by default. (In fact, we could quite easily make it the only option and be done with it.)
And yes, I think it does show the option on marking things as read.
-
I'm a bit lost in bug fixes, as you may understand from rev 1245-1246... :lol:
I'd like more opinions on setting quick mod checkboxes by default and NOT offering the ability to remove them. (I'm looking forward to it, too.. Eh eh.)
John, I noticed this topic: http://www.simplemachines.org/community/index.php?topic=438514.0
I don't usually read their Mantis but today I had a quick look and that's the first thing I found, and it's by you -- could you possibly read SM.org but that's the magic of following a couple of links. Anyway -- I wanted to ask, did you report this here as well...? Because it also happens in Wedge, doesn't it?
I added a isset() before that line (Admin.template.php:740 in Wedge), as per your suggestion.
-
I looked for a topic of mine with relevance but found none. It seems I actually did not repost it here. Did you add the fix in SVN or your local copy? I didn't see it in 1246.
-
Local only.
-
Bump.
Also... While I was on select boxes, I figured I should also fix buttons in IE. Their rendering was inconsistent, mainly in the icon position and padding area (and this also concerned Firefox.)
So I got rid of my icon sprite, replaced it with individual icons (total size lost: 1 byte!), positioned them as 'center', and used padding around text instead of line-height.
So... Turns out the icon positioning is fixed in all browsers. Yay!
However, padding is screwed up. It renders inconsistently in EVERY single browser. Even different versions of IE (67, 8 and 9) seem to render them differently. And it's all due to the padding... Uh!
From what I could guess, it seems that Firefox applies padding inside the button, and THEN it will also apply another arbitrary padding inside the content box once it's done. Yay, again. The line height thing was broken in Firefox because they use a freakin' "line-height: normal !important" in their default CSS, and no one can override their override. Apparently, it's because of some 'buggy sites'. Sure, guys... So you're ready to break ALL other sites for that?
Now, what I don't get is that on this site for example, I'm seeing the same sizes across all browsers:
http://www.webdesignerwall.com/demo/css-buttons.html
And finally, I tested my latest select box code in Chrome, and it exhibits the bug I fixed *yesterday*... >_< Perhaps I broke something else. Uh.
That was just my "Nao turned crazy again" moment...
Posted: January 12th, 2012, 03:34 PM
Oh, and demo site updated to rev 1248...
:edit: So, turns out the bug I mentioned in select boxes wasn't fixed yesterday. Well, I can simply confirm that I'd fixed it at one point, but it's likely that it was broken again by the time I committed... Hmm.
Posted: January 12th, 2012, 03:38 PM
Select box bug fixed... Found another one though... With optgroups... -_- Can't seem to fix it for now.
-
So... I pretty much have a usable button on Firefox and Opera (Firefox adds an extra pixel to the padding... Whatever, I'll live with that), but in the meantime I played with building my own button code and ended up with this in less than 5 minutes:
$(function () {
$('input[type=button],input[type=submit],button').each(function () {
$('<div class="webutton ' + (this.className || '') + '"' + (this.id ? ' id="' + this.id + '"' : '') + '>').data('that', $(this)).html($(this).val()).click(function () { $(this).data('that').click(); }).insertBefore($(this).css('left', '-99999em'));
});
});
It's pretty short... Innit? And it works quite well, and obviously allows for pixel-perfect buttons. Still, with that solution, buttons aren't immediately styled -- they have to wait for a bit to appear, like select boxes do.
Which solution would be best then..?
-
(Not a big fan of speaking to myself.... :sob:)
I wrote this NEAT little single-line function built from a couple of stackoverflow inspirations, that turns inputs into buttons.
$(function () {
$('input[type=button],input[type=submit],input[type=reset]').each(function () {
$(this).replaceWith($((this.outerHTML || new XMLSerializer().serializeToString(this)).replace(/^<input/, '<button')).html(this.value));
});
});
Inputs are cool, because their HTML is shorter. But:
- They don't accept :before and :after, because it's "semantically" frowned upon as they have no proper 'content'... Bollocks!
- Because of that, I can't add an extra 3D border without resorting to using multiple backgrounds...
- And multiple backgrounds are only supported by IE9+, so bye bye other IEs. Not that it matters much...
- Also, with my recent rewrite to make it, err, cross-browser pixel-perfect (which I still haven't achieved), I need to re-specify my entire list of backgrounds every time. Thankfully, gzip will notice that and limit the catastrophe to just a few lost bytes. Still, it looks ugly in the code... Perhaps also because I'm forced to generate strange CSS variables for IE at the end of the file.
Buttons are cool (except for the extra size) because:
- you can put straight HTML into the contents, duh!
- they accept :before and :after, AFAIK, and anyway it's easier to generate content around them,
- :before and :after are supported in IE7 and IE8,
- so I can add my extra borders to these pseudo-elements, and fix the problems mentioned above...
- and I supposedly can more easily style the entire thing across browsers. However this isn't the case in practice -- I noticed Firefox has the exact same behavior as with inputs. Uh...
So. What do you think is best?
And if <button> is best -- I suppose I should do a site-wide replace, shouldn't I...? Well, easier said than done. I have a feeling that I'll have to do it all manually... 1500+ occurrences and probably many jQuery tests for 'input' tags :-/ And the function above will, as always, give a noticeable delay before it's all transformed.
-
Hmm, I remember the one time I had to fight with magic button replacements, it was ugly. In short, I needed something that would be the size I set in CSS, with the text auto-centered vertically.
Initially a regular input was fine but then I wanted to include a GIF in it and the GIF was supposed to follow the text, meaning it wasn't as if the CSS could be used to do it (seeing how the button was like 150x100 with one or two words in the middle), and I ended up using a div to fake it and got very very frustrated with IE7 and 8 misbehaving the way they inevitably do with it >_<
I don't know what's for the best here, sorry.
-
As per my commit I chose to go for inputs. At worst I'll use the replace hack above with a span rather than a button; styling across browsers will be much easier.
-
So... I was looking into this annoying bug with Opera, where sometimes (an easy example is simply the thought editor in the sidebar), closing an opened select box will leave a trail of box shadow remnants.
From what I managed to gather... I was NOT able to find out WHY this happens (obviously an Opera bug, but HOW to trigger it or fix it elegantly?), but I managed to fix it consistently in several different ways:
- By using fadeOut() instead of animate() to remove the box. Easiest solution. Doesn't look as great, though....
- By wrapping the select box around a <div> tag with no class or anything. Anything that has display: block, basically. I cannot confirm, however, that it works consistently, and it's not the easiest either.
- By removing the display: inline-block from .sbox -- but then, whether using 'inline' or 'block' instead, the select box fills up the entire width available. (Possibly because of the inline-blocks it contains.)
So... A possible 'hack' would be, I suppose, to turn the select box into an invisible inline-block, get its dimensions, and then turn it back into an inline element. Or, just do that for Opera, obviously... But then we lose the 1px margin that I've set in the .sbox definition.
I'm a bit at a loss...
Anyone ever heard of this problem? Did you manage to reproduce? (any version of Opera + any recent version of Wedge)
Did you hear about difficulties with .animate() and trails left behind?
Or at least, do you have any 'favorites' in my suggestions above...?
-
So... By moving .inline-block to .details instead of .sbox, I'm finally fixing everything. It seems like Opera doesn't like it when a close parent has inline block status and we ask it to do some animation.
Unfortunately, although it fixes everything in the main content area, the sidebar thoughts behave even weirder... Now the dropdown will be shown on top of the display area, instead of below it. And if it's a drop-up, there will be a gap.
Now my best results are with position: relative set on .sbox and it being an inline box. I'm not sure how but it fixed itself. However, the dropdown is now hidden when the select box is enclosed in an overflow: hidden area.... I could possibly apply another kind of clearfix to these instead. But I'd rather fix that. Anyone knows how to fix an element being cut off when absolutely positioned and its parent is relatively positioned? I tried setting the parent to be absolute, it fixed it, and then obviously it broke layout in many places... -_-
Posted: January 17th, 2012, 10:20 PM
I think you're the only one who will have an opinion (a position?!) on this, Pete... Please comment, I see you've been reading this... :^^;:
This positioning thing is too unstable. There's always some reason for it to 'fail'. I think I'll go in the sad direction for now -- disabling animations for Opera. Which is twice as sad as could be: additional browser sniffing in sbox.js, and browser sniffing to the detriment of my favorite browser and test platform... :(
-
Reading, yes, following... that's another question entirely. I hate to say it but a lot of this lately has just gone over my head :(
-
You mean you've lost interest, or you think you've lost the required skill? :-/
-
Mostly the latter :(
It's simply that there's so much stuff to it I don't think I can grasp all that's required to make it work properly or all the consequences of the changes that are being discussed.
I much prefer simpler stuff like DB optimisation and plugin management...
-
Then focus on that (and on trying to establish a realistic to-do list with me ;))
My forte is front-end programming, and what have I been working on..? Front-end!
We're not paid, there's no reason we should in addition work permanently on shit we don't want to touch :P
-
In other news I have incidentally found functionality that is broken by this feature, but that probably needed rewriting anyway.
The admin pages that use prepareDBSettingContext theoretically support select with multiple items (i.e. that ghastly situation where you have to ctrl-click to select items from a listbox), but the new selectbox doesn't support this.
Not a real problem, since select-multiple is not actually used anywhere in Wedge (nor, I think, in SMF but included out of thoroughness) so what I'll do is remove multiple support, and replace it with a new type for multi-selections.
-
Well -- technically, what you wanna do is use <select size="something"> instead of just a select. Set something to > 0 and you'll get the multi-select feature.
-
Wish I'd have known that earlier >_< That'll teach me not to remember every nuance of the code :P
Since the JS selectbox is much better than what I was working, I'll run with that instead.
-
You can always remove stuff you don't like, you know... I won't blame you for that ;)
I'm just saying that Sbox doesn't support non-dropdown select boxes, so it leaves it to the regular GDI drawing, and thus gets to benefit from its features.
-
Oh... I thought it did something neat, and it seems my revert was a little too hasty. Oh well >_<
(I'm really not a fan of the classic Ctrl-click selector, I find it very irritating to use.)
-
Very sorry about the misunderstanding.
I could implement it, still. But I figured it'd add at least 300-500 bytes and for just a few underused places, avatar selection being the most prominent...
-
Eh, don't worry about it, more my fault for not double checking, and as it happens, I've already reimplemented my code.
In my case it's not the avatar selection I have in mind, but doing something with the notify-on-registration lark. Specifically, I wanted to have it so that you could select users who would be notified on a new registration rather than 'everyone who can approve registrations', but I can make use of it in other places, too.
-
Your multi-select thing -- is this what you're using in Notify Admins? Didn't have time to check the code... What did you replace the select box with?
Re: on-topic, I'm currently doing tests with a dropdown positioned absolutely relative to the body, rather than the select box itself... This seems to fix all problems met in Opera, but OTOH it also means that if the element is moved, the dropdown won't move along with it...
Fun times :P
-
It's a new field type called multi_select, which works like a select in receiving parameters and just displays it much as the inline_permissions does with a select box.
The values are serialized when saved (just as the old select multiple code)
-
OK, so I've been using the selectbox and I'm fairly sure I'm not doing it right, but I'd love some insight into this.
So, I have a selectbox that does something in its onchange event; it's set inline but the event delayer deals with it just fine, so all good up to that point.
The issue comes in when other stuff happens and I need to reset the selectbox (or otherwise force it to a certain value programmatically). There's only one way I can see of doing that and that's to use jQuery to select the original selectbox itself, .val(...) with the new value, then .sb() it to reload it, but I'm sure there must be a better way of doing it than that.
Setting selectboxes programmatically isn't going to come up often but it would be nice to know the best way to deal with it if it is going to happen - the code doesn't seem to have any kind of direct-set value function, and I'm loathe to add one manually because it's very complex code and I don't want to break it accidentally (or make it bigger)
-
There's no 'better' way than doing .sb() in the method chain after loading the value.
And yes, it 'looks ugly', but the alternatives were:
- adding a timer to determine whether the select box had changed (slow, resource intensive, silly)
- overloading the various jQuery functions that change attributes and stuff, to determine whether it belongs to a select box and thus trigger a timeout to redraw. Very slow, slightly resource intensive, complicated.
Please don't touch sbox.js itself, as you feared it's very, very prone to accidents :P (I broke it dozens of times, and I'm the one who wrote it!)
-
There's no 'better' way than doing .sb() in the method chain after loading the value.
I have no intention of touching sbox.js for just that reason ;)
-
Exactly the thing. There aren't THAT many opportunities to run sb(), so why waste time checking all other select boxes, I'd rather we get multiple user reports of select boxes that should be refreshed and aren't ;)
-
*nods* Works for me :)
-
On a related note, if we're styling selectboxes, would we not want to custom style checkboxes and radio buttons as well?
-
..Because they're already styled..? Or so?
My main issue with non-select box styling is that select boxes have this nice rounded corner effect, but I want the default skin to have straight corners, and I have trouble determining whether I should give select boxes rounded corners or not. Hence, same issue for the rest...
-
No, that's not what I mean - the select box actively looks different to what you get with the standard UI of your browser+operating system, and looks better for it, while the checkboxes/radio buttons are whatever you get served as standard, which varies from browser to browser and OS to OS. It just occurred to me it might be nice to put an image in for them (since IIRC it should be possible to do in CSS) instead of the stock ones, might give themers something nice to play with at least.
-
I don't know... I'm afraid it'd break something somewhere.
Any opinions?
(Also, the select box is styled entirely manually, except for the arrow. I like manual styling better :P)
-
If you did it with custom markup, sure it would break something. But it should be doable just with styling IIRC, in which case it shouldn't be able to break anything.
(Mind you, I have in one project actually implemented totally manual checkboxes before now, wasn't that much work and worked really well, IMO, better than using actual checkbox elements at least, heh. But I specifically didn't have to care about accessibility or anything like that)
-
Random oddity - it looks a bit weird on the gender selector in the profile area, seeing how there's only three options, the first is blank, so it collapses the width of the selectbox to fit.
-
Yep... I noticed that and found it funny, but didn't feel like it was worth adding a "Choose your gender" thing because people can choose an empty answer.
Could use a fixed class on it, though. It'd ensure the largest width is used. Would make more sense I guess!
-
Alternatively, how about "Prefer not to say" as the default?
(And, can we add the male/female icons via CSS like is done elsewhere? No sense having a fancy selectbox if it isn't using it to potential)
-
Icons? Good idea.
Want to do it? It's easy ;)
Prefer not to say: in 95% of cases it means I'm a woman and I'm taken so don't fuck with me. I'd rather avoid this choice ;)
-
Icons? Good idea.
Want to do it? It's easy
Prefer not to say: in 95% of cases it means I'm a woman and I'm taken so don't fuck with me. I'd rather avoid this choice
-
Oops, found a bug. Note that I'm not sure what the behaviour *should* be in this case, just that I know it's currently wrong.
-
It's a design choice, actually... Don't you like it? :^^;:
Look at Font Face, it'll also use the new font.
-
Oh, I like the fact the size is in the box, just that the text size is bigger than the box it's inside!
I like the font being shown like that, too, looks good.
/meis suddenly reminded of another micro feature he should add.
-
Oh, I like the fact the size is in the box, just that the text size is bigger than the box it's inside!
/meis suddenly reminded of another micro feature he should add.
-
Well, the alternative would be to increase the box size dynamically, but it would look even worse because it'd break the layout for the first line of buttons
Actually this one's really simple and will mean I can commit something useful this afternoon rather than wading through more FTP crap.
Posted: March 8th, 2012, 04:07 PM
And presto, micro-feature.
-
Nice :D
-
A stroke of genius
:wow:
-
Pete probably got scared when I removed so many of The fonts :P
-
Re: font code
$fonts = explode("\n", $settings['editorFonts']);
foreach ($fonts as $k => $v)
if (trim($v) == '')
unset($fonts[$k]);
else
$fonts[$k] = trim($v);
Dunno which is faster, probably my solution because it only applies trim once -- I'd like to suggest a one-line replacement (it's one of my things, you know it too well...):
$fonts = array_filter(array_map('trim', explode("\n", $settings['editorFonts'])));
The array_map will call trim() on all members, and array_filter() with no callback function will remove anything that looks like '0', 0, false, 'false' and empty strings. Since there are no fonts called '0' or 'false', it'll simply remove the empty lines. :)
-
Heh, that works. The extra trim came about because I wasn't thinking so clearly at the time of originally writing it, and yes that would be an improvement.
-
Could even ensure that comma separated fonts will be taken into account... ;)
(Heck, I wrote such a feature yesterday for the upcoming <languages> tag in skin.xml... Hopefully to be committed today.)
I'll do that at the same time.
-
Heck, I'll just copy it from my code :P
if (strpos($set, '</languages>') !== false && preg_match('~<languages>(.*?)</languages>~s', $set, $match))
$context['skin_available_languages'] = array_filter(array_map('trim', preg_split('~[\s,]+~', $match[1])));
As you can see, I only need to rename $match[1] to your $settings var... :P
I'll probably do without the array_filter in the code above, though, because come to think of it, I'm only doing a single in_array() call on it, so it won't care whether there are empty lines or not...