-
To answer the question you're thinking of -- yes, it's actually up and running, has been for about 5 minutes, seems to work, but I'm not extremely happy with the extra overhead... It adds like 1.1KB of code in the script footer area, and about 300 gzipped bytes to the script file. Really not happy with that...
Of course, it also 'removes' 300 bytes from the topic.js file (but what do I care.....), and it implements likes. (Not Ajaxively yet, obviously.) So that's about 110 bytes saved per thought, and as there are 10 thoughts on the homepage, it saves, ahem... 1.1KB of code. Whatever... But the repeated likes compress obviously much better than my mini-menu code.
1.0KB of code per page, and adds 275 bytes to script. (I was wrong earlier, it wasn't 300 originally, but 400.)
I can't do much better really... mini-menus simply take a lot of code.
I had to do something I really don't enjoy -- storing the events as strings, and then running them with .click(new Function('e', string))... OMG, my eyes!! eval()!!! If I tried to do it like in eves, i.e. by declaring anonymous functions, I'd have to somehow transmit the current ID to the event function in a way that's not very cool either... (global?!)
I'm just stuck for now.
Sure, it looks nice to have a mini-menu for thoughts. And if you load a topic page, you actually load less JS overall, because the overhead is only in the homepage, and in topic pages you're not forced to download the (internal to script.js) HTML for new thoughts, which represents about 150 bytes of gzipped code.
But I don't know whether it's worth it. It's fucked up.
-
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.
-
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.
However, I'm not satisfied with the difficult balance between byte-saving and complexity.
If you'll look at the source code for thought button creation, it's perfectly geared towards making it short and relatively clean.
Adapting this to a mini-menu required more bytes. It 'works', but I'm not exactly happy with all the extra luggage...
Additionally, you need to create three different arrays, which will then be used to generate the .mime() caller.
These arrays need to be done separately from the templates... Ideally, a mini-menu should 'behave' according to whatever data the *template* feeds it, I'd say.
So, we could move all the data to the DOM. For instance, instead of <div data-id="1234" class="acme">, do something like <div class="acme" data-id="1234" data-special="12345" data-re data-me>, where id=1234 and special=12345 obviously, and we declare a 're' menu entry and another 'me' menu entry. Or <... data-re="12345" data-me="12345">, but it forces repetition.
I don't fucking know what's best.
Plus, the awful Function eval stuff. I hate that.
All in all, maybe I should actually ditch the current mini-menu code and rewrite it entirely (not the looks but the internals), to explicitly set all entries explicitly instead of packing them into some barely understandable system with two-letter entries associated with a larger set of features.
Oh my, why do I always have to go for the complicated rewrites...?!
Or maybe I could just, hmm... I don't know... Separate the 'mini-menu generation' code from the 'mini-menu use' code, i.e. hovering it and showing it, should be in their own function (in script.js), while the generation could be pushed to topic.js for topic menus, and the HTML for thought menus or whatever.
I just don't know...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.
While most pages viewed will be topic pages, any homepage change is still going to have a huge impact.
Posted: February 14th, 2013, 10:27 PM
I saved another 30 bytes and sighed. Another bug has come up...
Damn.
Oh, it should be said that the generation code represents about 150 bytes, and the animation code is about 200 bytes (at the current time). It's really tempting to get rid of the generation code... :^^;:
Anyway... Time for bed. I'm useless right now.
-
Saved about 50 more bytes by rewriting a large portion of the mini-menu code.
- It no longer requires the bUseDataId param to be set. It'll just 'guess' by itself... (And yes, that saves bytes. Sigh.)
- No longer shows two different animations (depending on the parent's text-align: look here, it isn't the same whether you hover the Action or User menus.) Instead, the animation is done from the place your mouse cursor is, and thus is 'centered' from here. As such, it doesn't need aligning any further...
- Just some generally smarter code, such as storing all CSS and animation variables in a closure rather than in DOM data().
- Doing something I'm a bit ashamed of -- turning some of the $('<div></div>') DOM creators into $('<div>')... Although jQuery considers it 'bad practice' and has to 'fix' the tags afterwards, I'd just like to say that it just doesn't make a single difference for the user... The only difference is that the short version saved me a couple of bytes, so whatever... :P
Current overhead of mime() plugin is 342 gzipped bytes right now.
Which proves that I had my math wrong yesterday!
Also, generation code = exactly 155 bytes now.
-
Not happy with script size or outcome.
Not happy with thought menu layout vs the buttons we currently have.
Still, it's at least more in line with the current ui.
Tomorrow I'll try to restore alignments because I really like these.we shall see.
I'm so tired of this...
And I haven't even committed my sbox fix, I just realized...
(No one cares anyway. I shouldn't waste my time saving bytes like that... what matters is adding new features.)
-
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.
End of the day the only real judge is yourself.
-
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...
Posted: February 16th, 2013, 05:45 PM
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 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...
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.
-
- 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... :-/
-
- 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...
-
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!
That sort of makes it difficult to make extensible, which is something I did want to do as well.
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.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...
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.Non mobiles need a visual cue too...
Then use the same delay if any as the topic pages.
-
And you just know that the 1 in 100 chance will come back to bite. Still there's always the clear-file-cache ;)
What do you think?
I realize I'm pretty mental, but at least it means I'm half cured.
12 bytes before compression.
-
And you just know that the 1 in 100 chance will come back to bite. Still there's always the clear-file-cache ;)
Where would we want to use buttons, exactly?
There aren't many places I can think of where this would actually be an issue.
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... ;)And unless the word Android is used elsewhere on the page, it's not going to compress particularly well anyway ;)
-
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.
Anywhere outside of an ul.actions block... Well, I mean I'm sure that plugins would be glad to be able to use them.
-
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.
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..?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.
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... :)
-
Yup, reuploading the files will fix it, just as getting the admin to clear the file cache would too.
but don't forget that we use the Like button in Top Likes stats, and that we had trouble making it show up..
-
Yup, reuploading the files will fix it, just as getting the admin to clear the file cache would too.
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.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.
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.
-
Actually, no, since the date is taken from the latest file, so it'll just reuse the same date...
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.
-
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...!Most FTP clients seem to use current system date when uploading...
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.
Then break it down and deal with it in stages. Especially with optimisation. Do that last.
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.Use what looks best. Something that's a few bytes more but looks better would be better appreciated by the users.
Although I think we should consider changing some of our reply/quote/whatever icons.The very right would be better. I don't know that it would be 'much' shorter. But it's where it should go, IMO.
What do you think about the mini-menu as it is, anyway..?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.
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:
-
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!
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.
Although I think we should consider changing some of our reply/quote/whatever icons.
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, the issue I'm referring to is there should be a space either side of the : in the ternary and there isn't ;)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.
But if they can remain accessible without being forced into the action menu, that should be sufficient.
-
But surely if you empty the cache you're forcing everything to be rebuilt from whatever the current 'master' is?
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... ;)How about I look through Fugue and see if I can find some suitable replacements?
Also, the issue I'm referring to is there should be a space either side of the : in the ternary and there isn't ;)
Fixed locally...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.
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
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.
- 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...
-
'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.
-
The actions menu doesn't work on my iPad :(
Incidentally neither does quick reply expanding.
-
The actions menu doesn't work on my iPad :(
Incidentally neither does quick reply expanding.
-
Yeah, I'm not using iOS 6.
-
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.
-
Worry about it when you feel better ;)
-
Actually only fails when logged off.
Strange. I thought it'd at least show the In Context link....
(My fever is bearable. more than my inability to work on my PC, really.)
-
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?!
-
Yay for mobile bugginess? iOS has done something similar for a while actually, bumping you back to whatever # you were on (which made using the top menu to return to the front page impossible without scrolling up there twice from a thread but that's another story)
-
Speaking of mobile bugs. wireless is broken in chrome beta and maybe others... dunno if it's due to today's update
-
Fixed.
And I dropped my s3 on concrete while testing. YAY.
Screen gets new big scratch in the middle. All four corners are fucked up.
I miss good old cheap phones that you could drop every day.
-
Like
And I dropped my s3 on concrete while testing. YAY.
Screen gets new big scratch in the middle. All four corners are fucked up.
I miss good old cheap phones that you could drop every day.