Wedge

Hmm, lots to think about.

I'd argue that minimenus would be nice to have as generic code available everywhere, not just in topics, and I can see places where mod authors might want to include them.

Seems to me that it would be worth it because it would usually be cached, it's the file most likely to be cached and available after jQuery.

It's OK, I'm not happy with any of the stuff I've done today either. I've been experimenting :whistle: but nothing I want to share yet.

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!

I know the feeling.

The stuff I have is not commit-ready and I refuse to commit it in the state it's in because it just doesn't work properly, before I even get into the performance issues I can see that might occur.[1]

End of the day the only real judge is yourself.

1.	All I can say is that the table in question is heavily used and more than one SMF/Wedge bug has been because of its reliance on MyISAM ordering. And that combining that with this you might realise what I've been doing today.

If you're working on making use of Sortable in 'public' areas of Wedge......... Please consider using a plugin that doesn't require jQuery UI.
Seriously, I won't give a pass to something that forces people to download jQUI on any public page.
Doing it on a page that's called through the action of a registered member is more acceptable (which is why you had my okay for sorting pinned topics), but it's still something to be careful about.
I haven't been spending an entire day on saving 50 measly bytes in script.js just to have you add 100KB to the lot... :P

Well... I only put the sortable in a side page that isn't likely to be used that often anyway (it's not a regular member page, but a staff member, it's only just above the admin panel really)

But the area I'm talking about is an admin area. ;)

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.

You know me by now I'm not going to add bytes to every page unnecessarily, it's why I haven't added the search box thing I've thought of for ages because it would add bytes on pretty much every page of usefulness. But I'll see.I'm a big user of the thoughts area, it's quite important to me ;) What I do know is that the current buttons have issues - namely when using mobile, and currently I'm seeing cases where a long thought with likes can be impaired by the current buttons on a narrow window (there's a thought that has a long content, but if I go to click on the popup, the buttons are in the way)I think we really need to try it with a wider audience. My gut says 200ms should be fine for that page given its uses.

- By order of optimization importance: index template HTML, script.js, any other JS file. I'd suggest looking into providing the bare necessary, such as <div id="searchx" data-tid=topicID data-bid=boardID></div>, and then using a cached JS block to suggest a search destination. (Isn't it a good thing that $txt can be cached too by now? :P)

- Mobile is something I strive to look into, but it's not my absolute priority. I did fix something related to this today though, I added 13 bytes of JS to disable username clicks on Android if they're associated with a mini-menu. Fair trade. (..............And here's me thinking about adding browser name/version to JS filenames :lol:)
Anyway, all I can say is, mobiles need a visual clue for a menu, so I guess it's best to show one of the '+' icons and just have the menu show up when hovering these...

- Can't use one delay in a page and no delay in another... :-/

That sort of makes it difficult to make extensible, which is something I did want to do as well.And if you did that you'd erase the 13 bytes of savings. -android-4.0 for example is 12 bytes... and it will only be used once on the page...Non mobiles need a visual cue too...Then use the same delay if any as the topic pages.

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.