Wedge

Not 100 but 100.000... (I don't remember if it's spelled 100,000 or 100.000 in the UK... It's 100 000 in France :P)Anywhere outside of an ul.actions block... Well, I mean I'm sure that plugins would be glad to be able to use them.It's a non-issue in the end.
I reverted back and recompiled, and discovered that the code was actually 10 bytes larger than my 'fixed' one...
The reason I'd brought it down by 100 bytes was that at one point, all of the buttons were in their own root class *but* unextended. And a button that just says "background-position" without an actual background to move is pretty much useless... ;)Oh, still better than 12 bytes :P

And there we go again... Plenty of new posts/topic updates... :^^;: And I still haven't had time to catch up with last week's!Hmm... Well, I guess that one's still doable.

Oh, a funny CSS extensibility issue I had tons of problems with before -- and still do right now.
Remember how our buttons are based on "ul.actions a", because it solves some inheritance issues and also makes it compress better...?
Well, this system added a problem for .unlike_button, because it wouldn't keep the requested background position.

So, what was my stupid idea of the day..?
"Give up on that strange inheritance thing, and use root classes for buttons."
Oh my.
So, I created a 'virtual button' virtual class, which loads the sprite and sets default paddings and height. Because of the paddings, I was forced to inherit all buttons from that virtual class, even those that overwrite the sprite image. First bad thing...
Then, the .more_button would be screwed up. Why? Because it inherits two classes (the virtual button and .upshrinks), and the upshrinks image is defined BEFORE the virtual button... However, it obviously needs the upshrinks image. So, I had to move the virtual button to before upshrinks... More gzipped bytes. -_-

So, right now it SEEMS to be working for everything...
At a cost of over 100 gzipped bytes.

I spent 2 days on JS files to save a hundred bytes and partly counter the impact that moving the .mime plugin to script.js would have on the main JS file. In the end, it's all lost because of that new problem...

I'm tempted to go back to how it was a few hours ago. But it also means dropping the possibility of finally being able to use buttons anywhere, without them having to be inside an ul.actions class...

What do you think?
I realize I'm pretty mental, but at least it means I'm half cured.12 bytes before compression.
Also, my latest local files save about 8 bytes in the headers compared to the committed one. I achieved that through passing the $latest_date variable through a % 1000000 operation. So it shaves a few chars off the beginning of the date. Each time you're regenerating the cache files, there's one chance out of a million that the filename will conflict with an earlier version of the cache. And one out of one million means that even if it happens, nobody's going to have the previous version in their cache, it'll be long gone (hopefully)... Heck, I could even reduce it to % 100.000 (I think that's what's currently in my local install), it just means it's one chance out of 100.000...

Anyway.The '+' button is a better visual clue that whatever there was before...I think I'm probably going to remove the delay entirely.

Good then.

Alright, I'm still stuck on mini-menus...
I made my peace with the idea of repositioning the menu horizontally based on the mouse position. While it's very nice if the menu hover area is quite large, when it comes to user names and actions, it makes more sense to have the mini-menu position itself right below the element, rather than a few pixels off to the right or left... (Plus, the shortest code I managed to write for this still took an additional 30 bytes... For just a single line...)
The 'solution' for thoughts is, I suppose, to limit the hover area to somewhere small. Something like an "Actions" button that would show on every line. I don't know... Any ideas..?

I know that this feature rewrite doesn't excite anyone right now (and me even less), but for anyone who's been using the thoughts feature, especially on the homepage, this will have an influence on your perceived enjoyment of it...

Oh, also I'd like to know if you think a delay before opening the mini-menus is good or not...
It doesn't add a lot of bytes, because the code is mostly copied from the main menu stuff, and I added it because I originally had the entire area of the thought list hoverable, so it really looked ugly to have a mini-menu open (and close) for each single thought entry just because I was scrolling through the page and moving the mouse around quickly... I added a 200ms delay, which 'works' nicely there, but is annoying in user name & action menus.
I could either reduce the delay to 50ms or so, or completely remove the code and assume that mini-menus will always be applied only to a limited portion of hoverable content.

My stuff is commit material. It just isn't "proud author" material. You know. This thing you commit not because you like it but because it would probably hurt more not to commit it, and you start wondering if you're committing to show the amount of work you put into the thing before you get to revert it...

Bed time!

Is this feature really something we're missing..?

There's a topic about that, like....... right below yours or not far :whistle:

But this is how I suggested to do it, AFAICR..? Or am I wrong?