Wedge

Oh fuck.
Sbox doesn't work anymore in chrome for android either...
Open the board changer, and try to scroll through it... sent to page top. Eh?!

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.

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

Oh... So, the removal of fulltext is what was pre-required to switch bodies to mediumtext...?
So, one bird with two stones? :)

Oh, all right...

Okay, bed time for me. I see you just made another commit that changes language files... I'm a bit wary of language files these days... :^^;:

I never even noticed that bug..?!

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... ;)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.Ah, sorry, I missed that one... Poetic justice? ;)
Fixed locally...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...
- 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... :^^;:

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..... :^^;:

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...

160 bytes is usually a bit short for a regular conversation (you don't always 'think' of compressing details into the beginning of a post, unlike Twitter...), so OTOH I'd rather not waste too many bytes on a feature that's SEO-only. (Heck, it it were me, I'd just dismiss the meta description tag entirely... :^^;:)
So, a good compromise I suppose..?

BTW, is it worth putting the … stuff in the string? It looks a bit odd, when looking at the HTML...

I like the idea. I've had on occasion been forced to do 'stuff' => 'stuff' indeed, and this would make it neater.

Just two remarks:
- escliteral isn't an exciting name ;) I could go with 'literal', though. Or 'escape', or whatever...
- we might get people complaining that there's a bug here or there because "a variable is missing its value"... Although I doubt it -- coders usually are smart enough to figure things out without checking the source :P