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

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #105, on January 10th, 2012, 01:28 PM »
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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #106, on January 10th, 2012, 06:16 PM »
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.
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 #107, on January 10th, 2012, 06:21 PM »
Shouldn't we enable it by default? I thought it was...

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Selectbox
« Reply #108, on January 10th, 2012, 10:26 PM »
Quote from Lurker on January 10th, 2012, 06:16 PM
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.
doesn't it also show the option to mark selected topics as read, thus showing for everyone?
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #109, on January 11th, 2012, 02:51 AM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #110, on January 11th, 2012, 09:18 AM »
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.

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Selectbox
« Reply #111, on January 11th, 2012, 09:39 AM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #112, on January 11th, 2012, 11:29 AM »
Local only.
Re: Selectbox
« Reply #113, on January 12th, 2012, 05:50 PM »
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.
Re: Selectbox
« Reply #114, on January 13th, 2012, 09:47 PM »
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:

Code: [Select]
$(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..?
Re: Selectbox
« Reply #115, on January 14th, 2012, 06:34 PM »
(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.

Code: [Select]
$(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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Selectbox
« Reply #116, on January 14th, 2012, 11:54 PM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Selectbox
« Reply #117, on January 15th, 2012, 12:37 AM »
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.
Re: Selectbox
« Reply #118, on January 17th, 2012, 05:47 PM »
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...?
Re: Selectbox
« Reply #119, on January 17th, 2012, 10:50 PM »
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... :(
« Requiring JS in the admin panel
Some admin menu changes »