Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #15, on February 16th, 2013, 11:56 PM »
And you just know that the 1 in 100 chance will come back to bite. Still there's always the clear-file-cache ;)
Quote
What do you think?
I realize I'm pretty mental, but at least it means I'm half cured.
Where would we want to use buttons, exactly? There aren't many places I can think of where this would actually be an issue.
Quote
12 bytes before compression.
And unless the word Android is used elsewhere on the page, it's not going to compress particularly well anyway ;)
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,079
Re: Mini-menu implementation
« Reply #16, on February 17th, 2013, 10:44 AM »
Quote from Arantor on February 16th, 2013, 11:56 PM
And you just know that the 1 in 100 chance will come back to bite. Still there's always the clear-file-cache ;)
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)
Quote
Where would we want to use buttons, exactly?
Anywhere outside of an ul.actions block... Well, I mean I'm sure that plugins would be glad to be able to use them.
Quote
There aren't many places I can think of where this would actually be an issue.
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... ;)
Quote
And unless the word Android is used elsewhere on the page, it's not going to compress particularly well anyway ;)
Oh, still better than 12 bytes :P

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #17, on February 17th, 2013, 02:55 PM »
No, I was being flippant. It's a joke from H2G2 about a ship fitted with a device that makes something infinitely improbably and the 'quasi reciprocal nature of the universe' means that something that is supposed to be infinitely improbable is bound to happen almost immediately.
Quote
Anywhere outside of an ul.actions block... Well, I mean I'm sure that plugins would be glad to be able to use them.
I'm not sure where it would be useful, though. I'm fairly sure that anyone using such buttons would just drop the relevant ul in the first place.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mini-menu implementation
« Reply #18, on February 17th, 2013, 03:13 PM »
Quote from Arantor on February 17th, 2013, 02:55 PM
No, I was being flippant. It's a joke from H2G2 about a ship fitted with a device that makes something infinitely improbably and the 'quasi reciprocal nature of the universe' means that something that is supposed to be infinitely improbable is bound to happen almost immediately.
Ah, yes, thoughts to an enthusiastic whale who left us in its prime!

Still, there are two ways to 'fix' the problem if it ever happens...
- Server: just reupload the index.css or script.js files. Or whatever is needed. This will change the number obviously...
- Client: empty file cache... Or, quite simply, don't do anything: chances that if the number is in conflict with an earlier version of the file, it was not 100,000 seconds ago, but 50,000 * 100,000 seconds ago in average, that is once every 158 years... Heck -- if anything, I could simply do a mod on 10,000 because that means potentially means one conflict in average per 1.58 years... And who exactly has a hard drive large enough to keep a cached copy of whatever JS/CSS file on whatever website for 1.58 years..? I don't think any file's filetime in a cache is more than a few weeks. Are there any studies on this..?
Quote
I'm not sure where it would be useful, though. I'm fairly sure that anyone using such buttons would just drop the relevant ul in the first place.
Possibly (probably), but don't forget that we use the Like button in Top Likes stats, and that we had trouble making it show up... With my rewrite, it no longer is a problem. Also, as I managed to save a few bytes instead of it taking an extra 100 bytes as I originally thought, I don't really have another reason to keep these buttons as children of ul.actions any longer.

Oh, BTW, I've come to a point where I'm relatively satisfied with the thought rewrite. Expect a commit today or tomorrow at the latest... :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #19, on February 17th, 2013, 03:44 PM »
Yup, reuploading the files will fix it, just as getting the admin to clear the file cache would too.
Quote
but don't forget that we use the Like button in Top Likes stats, and that we had trouble making it show up..
Did we? I had nothing to do with that stats block (other than a query bug fix after thought likes were implemented), but it seems to me that using a separate like image would be a simpler solution to that.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mini-menu implementation
« Reply #20, on February 18th, 2013, 10:39 PM »
Quote from Arantor on February 17th, 2013, 03:44 PM
Yup, reuploading the files will fix it, just as getting the admin to clear the file cache would too.
Actually, no, since the date is taken from the latest file, so it'll just reuse the same date...
As I said -- either reupload the file, or just hope that the conflict is old enough that no one has a cached copy on their computer any more.
Quote
Did we? I had nothing to do with that stats block (other than a query bug fix after thought likes were implemented), but it seems to me that using a separate like image would be a simpler solution to that.
Hmm yeah then I probably did that by myself...
It was complicated. And I'm thinking I should get rid of .top_likes as it is right now. Dunno.

Heck I'm drowning in complexity... For instance, one of my most trivial issues is that I noticed that the mini-menu's .remove_button uses delete.gif, while the thought system's remove button uses delete.png, which is a different (and better looking!) icon... I'm considering dropping delete.gif and replacing it either with delete.png, or a smaller version of it. Again: dunno... :-/

And one of my most annoying ones is that I don't know where to place the Actions button in the thought list... To the very left? Looks strange. Right after the date? Not aligned. Right before the thought author? Looks strange, again... At the end, aligned in a new column? This makes the thought much shorter... Not cool.
I also had tons of bugs with my mini-menu rewrite. Ended up having to revert a few lines I was quite proud of... And losing another 20 bytes. I *knew* this stupid extra code was there for a reason... Yet, I attempted to remove it. My loss.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #21, on February 18th, 2013, 10:49 PM »
Quote
Actually, no, since the date is taken from the latest file, so it'll just reuse the same date...
Most FTP clients seem to use current system date when uploading...
Quote
Hmm yeah then I probably did that by myself...
It was complicated. And I'm thinking I should get rid of .top_likes as it is right now. Dunno.
Hmm.
Quote
Heck I'm drowning in complexity...
Then break it down and deal with it in stages. Especially with optimisation. Do that last.
Quote
For instance, one of my most trivial issues is that I noticed that the mini-menu's .remove_button uses delete.gif, while the thought system's remove button uses delete.png, which is a different (and better looking!) icon... I'm considering dropping delete.gif and replacing it either with delete.png, or a smaller version of it. Again: dunno... :-/
Use what looks best. Something that's a few bytes more but looks better would be better appreciated by the users.
Quote
And one of my most annoying ones is that I don't know where to place the Actions button in the thought list... To the very left? Looks strange. Right after the date? Not aligned. Right before the thought author? Looks strange, again... At the end, aligned in a new column? This makes the thought much shorter... Not cool.
The very right would be better. I don't know that it would be 'much' shorter. But it's where it should go, IMO.
Quote
I also had tons of bugs with my mini-menu rewrite. Ended up having to revert a few lines I was quite proud of... And losing another 20 bytes. I *knew* this stupid extra code was there for a reason... Yet, I attempted to remove it. My loss.
Yeah, that sort of thing sucks :( This is why I don't do optimisation until late in the day, if at all. I tend to hammer it out, iterate it, fix the bugs in it and then (and only then) worry about making it smaller. Like the change in r1930 about fixing the ternary, IIRC there wasn't even that if to start with, it only came about as a bugfix, and even though there's currently a missing space by the :, I would personally have been happy with it how it was - ternaries make it smaller, yes, but they do make it harder to follow again later :/ It's all good, though.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mini-menu implementation
« Reply #22, on February 20th, 2013, 08:09 PM »
Too many posts... :^^;:
And I really tend to overlook them all when there are too many.
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!
Quote from Arantor on February 18th, 2013, 10:49 PM
Most FTP clients seem to use current system date when uploading...
Yes, which is why reuploading the file will fix the problem, but not emptying the cache... Because the original CSS/JS files will keep their original date ID.
Quote
Quote
Hmm yeah then I probably did that by myself...
It was complicated. And I'm thinking I should get rid of .top_likes as it is right now. Dunno.
Hmm.
(Done.)
Quote
Then break it down and deal with it in stages. Especially with optimisation. Do that last.
I usually do that... And end up forgetting what I was doing the day before.
Creating my changelog and checking diffs in Tortoise is the only way I manage to keep up with my own changes and whatever I need to fix before the proper commit.
Quote
Use what looks best. Something that's a few bytes more but looks better would be better appreciated by the users.
In this case, it wasn't about choosing, it was just about removing a duplicate file... ;)
Although I think we should consider changing some of our reply/quote/whatever icons.
Quote
The very right would be better. I don't know that it would be 'much' shorter. But it's where it should go, IMO.
In the end I pushed it to the left after the date, to be consistent with the mobile version where both date and action menu are in the first line, followed by a newline and the thought.
What do you think about the mini-menu as it is, anyway..?
Quote
Yeah, that sort of thing sucks :( This is why I don't do optimisation until late in the day, if at all.
I'd rather avoid it, but it's the obsessive-compulsive me talking at that point. See, I'm perfectly okay with adding 500 bytes for a cool new feature. I just don't think it's okay to add 500 bytes when it could be 300 with just some more effort... :^^;:
Quote
I tend to hammer it out, iterate it, fix the bugs in it and then (and only then) worry about making it smaller. Like the change in r1930 about fixing the ternary, IIRC there wasn't even that if to start with, it only came about as a bugfix, and even though there's currently a missing space by the :, I would personally have been happy with it how it was - ternaries make it smaller, yes, but they do make it harder to follow again later :/ It's all good, though.
I don't understand what you're trying to say about the ternary fix...
Anyway, that one is just me trying to push short code into a single line when it's spread over 4 lines... That's just me.

Also, regarding the reason I changed the mini-menu code to always create all entries at load time, rather than hover time. Yes, 70ms (for a full page) isn't something to be ignored. If performance becomes an issue, I'll gladly rewrite my code to use pure JS instead of jQuery (it's all about manipulating document fragments...)
However, the reason, as I said, is that with this, I can do something pretty smart.

- Move ALL action entries to the mini-menu code. (Saves at least 200 gzipped bytes per page...)
- Calculate the current div width. Add entry to div. See if entry goes to a new line. If not, continue. If yes, cancel that one, move it to the action menu, and keep adding to the action menu for the remaining entries.

This would basically allow us to show the action menu on any screen width, and then ensure that smaller screens get an action menu when it's too much for them.

I don't know if I'm going to implement this immediately, but what do you think of it..?
Posted: February 20th, 2013, 04:39 PM

I think the main (only?) drawback to this method is that if JS is disabled on your browser -- you don't get to see any option at all... This is why Wedge currently shows the two most important settings (quote and modify) as regular links, not part of the menu.
Posted: February 20th, 2013, 06:30 PM

BTW, I'm working on allowing other thought pages to use the mini-menus.

Currently, I have the 'All thoughts' page showing it, as well as Likes. It doesn't show the Like/Unlike button in the menu though (just the likes count outside the menu.) Also, it's still buggy, so I can't actually edit or post answers.

I was a bit torn between copying the Homepage code to the other functions, but then I decided to instead try to merge both into one... So the homepage now includes the Thought source, but it's kinda annoying, the homepage code has some really custom stuff that the other pages don't, and vice-versa... Though job. Is taking longer than I'd like...
Will eventually complete it, though.

Oh, and the script.js file is now 22 bytes shorter than yesterday... :lol:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #23, on February 20th, 2013, 08:13 PM »
Quote
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!
Practice and good time management ;)
Quote
Yes, which is why reuploading the file will fix the problem, but not emptying the cache... Because the original CSS/JS files will keep their original date ID.
But surely if you empty the cache you're forcing everything to be rebuilt from whatever the current 'master' is?
Quote
Although I think we should consider changing some of our reply/quote/whatever icons.
How about I look through Fugue and see if I can find some suitable replacements?
Quote
I don't understand what you're trying to say about the ternary fix...
Anyway, that one is just me trying to push short code into a single line when it's spread over 4 lines... That's just me.
Shorter code is not always ideal. Had I written that from the off, it probably would have been a ternary but originally it was a two-line affair and became a four line affair; refactoring to a ternary just never occurred to me at that point.

Also, the issue I'm referring to is there should be a space either side of the : in the ternary and there isn't ;)
Quote
This would basically allow us to show the action menu on any screen width, and then ensure that smaller screens get an action menu when it's too much for them.

I don't know if I'm going to implement this immediately, but what do you think of it..?

I think the main (only?) drawback to this method is that if JS is disabled on your browser -- you don't get to see any option at all... This is why Wedge currently shows the two most important settings (quote and modify) as regular links, not part of the menu.
I'd argue that the Quote/Modify buttons serve a higher purpose than merely being available if there's no JS - they also exist to be prominent and easily accessible being the most common actions you're going to perform.

But if they can remain accessible without being forced into the action menu, that should be sufficient.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mini-menu implementation
« Reply #24, on February 21st, 2013, 11:15 PM »
Quote from Arantor on February 20th, 2013, 08:13 PM
But surely if you empty the cache you're forcing everything to be rebuilt from whatever the current 'master' is?
Hmm...
Emptying cache: Subs-Cache will renew it.
Building cache = getting the file list, loading all files, generating filename. Filename = built from the most recent last modified date of the filelist.
If you empty the JS/CSS file caches, the regenerated cache files will have the same date number (in the filename) as the earlier cache versions. The only way to change it is to reupload one of the files from the file list. And you don't need to empty the cache... ;)
Quote
How about I look through Fugue and see if I can find some suitable replacements?
Hmm, I dunno, I kinda like the existing icons, just not ALL of them... Ideally, we should make variations but it's a bit weak.
Quote
Also, the issue I'm referring to is there should be a space either side of the : in the ternary and there isn't ;)
Ah, sorry, I missed that one... Poetic justice? ;)
Fixed locally...
Quote
I'd argue that the Quote/Modify buttons serve a higher purpose than merely being available if there's no JS - they also exist to be prominent and easily accessible being the most common actions you're going to perform.
Yes, they're prominent, but if you'll browse with iOS, you'll see that Wireless doesn't show them either... It only shows the action menu. I haven't seen anyone complain about that, BTW...

We can either provide the same HTML as now, in which case Quote/Modify will always be shown and the rest will depend on the available room. We can provide a fully JS version, in which case (unless JS is disabled...) Quote/Modify *will* show up, as well as all of the other options because, well, there IS enough room in a regular skin for all elements... Or we can provide all buttons in HTML, without mini-menu shorthands, so that everything's available with JS disabled and still moved to mini-menus if not enough room. Of course, that one is expensive in terms of HTML size...
Posted: February 20th, 2013, 10:56 PM
Quote from Nao on February 20th, 2013, 08:09 PM
Currently, I have the 'All thoughts' page showing it, as well as Likes. It doesn't show the Like/Unlike button in the menu though (just the likes count outside the menu.) Also, it's still buggy, so I can't actually edit or post answers.

I was a bit torn between copying the Homepage code to the other functions, but then I decided to instead try to merge both into one... So the homepage now includes the Thought source, but it's kinda annoying, the homepage code has some really custom stuff that the other pages don't, and vice-versa... Though job. Is taking longer than I'd like...
Will eventually complete it, though.
- I merged the Home function with the latestThoughts one... It worked... But it had the unforeseen effect of taking 16 seconds (!!!) for the main query in latestThoughts mode. This was because I was doing a single query for everything, just like on the homepage, when latestThoughts is optimized "à la SMF" to get the thought ID list first, and then the contents (it's really, really much better to execute two fast queries than one long one... Something I didn't know about MySQL until last year, I'm afraid.)
- So, I reverted, and did it in two functions... The only change is the HTML generated by latestThoughts, which is closer in spirit to the Home one.
- Homepage works. All Thoughts works, except for "Reply" button (Modify works), because of a HTML problem. I'll look into that tomorrow... (Bed time.)
- Profile thoughts are untested.
- In Context thoughts still have no support for mini-menu.
- All in all, what a mess... :^^;:
Posted: February 20th, 2013, 11:00 PM

Oh, BTW, something else that's funny... Half an hour ago, I launched phpMyAdmin to analyze more thoroughly the query that took 16 seconds. I had a very narrow browser window at that point to test different thought widths. And I noticed the menu had a "More..." link. Then I expanded the window... And the menu items were made primary.

So, not only did I *not* have a very original idea since it was already implemented in phpMyAdmin (which is not particularly well known for its modernity and boldness!), but it's actually a better implementation that I envisioned myself because it does the refitting at $(window).resize() time, while I was only looking into doing it at $.ready() time..... :^^;:
Posted: February 20th, 2013, 11:04 PM

This thing has been driving me crazy...
I know there aren't any CSS wizards out there, but I'll still try my luck.

Attached is a zip file containing two h264-encoded videos. (They're very short, so the file is, too!)
arrow 1.avi = the original mini-menu animation
arrow 2.avi = the current animation

The only difference is that #2's arrow is horizontally static, it's already in place and not moving except vertically (barely noticeable).
That's okay, it was as intended, but to be more specific, when I did my CSS/JS changes, the arrow started moving the other way (from right to left), rather than what video 1 shows (left to right).
I absolutely loved the left to right animation, and I actually have a copy of Firefox running with the 'old' code in cache, and can reproduce this, and Firebug allows me to set a border on the arrow's div (which is at .right.mimenu li:first or something like that)... And the div enlarges from left to right, i.e. it doesn't fill the width of the menu completely at the beginning of the animation, it's actually narrower and left-aligned. By the time the animation finishes, the div is now filling the entire menu, and thus the 66% horizontally positioned arrow is at the correct position, going from left to right.
But I just can't reproduce the fact that the container div starts out narrower and left-aligned... I don't get it. The CSS is really the same between the two versions, but they don't behave the same...
It's probably a JS problem, but same here: same starting and ending positions in JS on both versions...

Drives me crazy, really.

So, in a future commit I'll be considering reverting to the 'right to left' animation (setting a 80% position on the background arrow), which I think looks better, with the only issue being that the arrow isn't positioned the same depending on the menu width.
I could try and implement a CSS3 animation from within the CSS file... It might actually work... But I think it's doomed in advance.

Any ideas then..? For those with SVN access, feel free to revert to an older rev (before today) and analyze the CSS and JS for the animation... Because right now, I'm stuck. And I wrote it! (And, I'm ashamed to admit, the original left-to-right animation wasn't my doing... It was a glitch that occurred during development, and I liked it so much that I made sure to keep it that way. But I obviously broke it during my rewrite and forgot about it. Only realized today that the broken behavior is broken.)

Ah, well, anyway...

 arrows.zip - 97.76 kB, downloaded 74 times.

Re: Mini-menu implementation
« Reply #25, on February 22nd, 2013, 10:14 AM »
'Fixed' by replacing 'left, top: 0' with just 'top: 0' in the CSS for the arrow stuff...
Don't ask me why. It didn't make sense yesterday. It doesn't make any more sense today.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Mini-menu implementation
« Reply #26, on February 22nd, 2013, 03:26 PM »
The actions menu doesn't work on my iPad :(

Incidentally neither does quick reply expanding.

MultiformeIngegno

  • Posts: 1,337

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Mini-menu implementation
« Reply #29, on February 23rd, 2013, 12:29 AM »
Probably due to this.

bugs.jquery.com/ticket/13282

They mention qtwebkit but I have the same error except for nodelist instead of object. In iOS 5.
I already saw that the got version had reverted so it should work in 2.0 final.
Posted: February 23rd, 2013, 12:19 AM

Also seems to fail in Chrome Beta for android... bugger.