Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
2461
Features / Re: New revs
« on October 4th, 2013, 04:29 PM »
rev 2265 -- the usual "pre-bigger-commit" bunch of small fixes/additions.
(10 files, 4kb)
* Making the footer JavaScript outputter available to hackers. It's needed for the next commit... (index.template.php)
! IE 10 supports flex value 'space-between', but it needs to be renamed to 'justify'. (Class-CSS.php)
! Static method call in a non-static class constructor? Oh well, at least it still worked... So, whatever. (Class-Skeleton.php)
! Always initialize the rtl variable (for @if tests), for clarity mainly. Although, I'll have to admit, I haven't tested RTL mode in quite a while... Also saved a few lines by replacing a list/each pair with a key/current pair. I'm like that. (Load.php)
! Wedge was leaving some blank lines in the HTML source after soft-merging posts. (Subs-Template.php)
! Topic list had too narrow a width in mobile skins. Hmm, I have a feeling that fix is in need of something more distinguished... (MessageIndex.template.php)
* Commenazi, and a reminder to self. (ManageMaintenance.php, Subs-Post.php, Subs-Members.php)
* Moved the JumpTo text from the basic HTML source to the script.js file, where at least it's cached. Only saves a few bytes per page, but why wouldn't I want to..? Plus, hey, it's a free fix for infinite scrolling... (index.template.php, script.js)
(10 files, 4kb)
* Making the footer JavaScript outputter available to hackers. It's needed for the next commit... (index.template.php)
! IE 10 supports flex value 'space-between', but it needs to be renamed to 'justify'. (Class-CSS.php)
! Static method call in a non-static class constructor? Oh well, at least it still worked... So, whatever. (Class-Skeleton.php)
! Always initialize the rtl variable (for @if tests), for clarity mainly. Although, I'll have to admit, I haven't tested RTL mode in quite a while... Also saved a few lines by replacing a list/each pair with a key/current pair. I'm like that. (Load.php)
! Wedge was leaving some blank lines in the HTML source after soft-merging posts. (Subs-Template.php)
! Topic list had too narrow a width in mobile skins. Hmm, I have a feeling that fix is in need of something more distinguished... (MessageIndex.template.php)
* Commenazi, and a reminder to self. (ManageMaintenance.php, Subs-Post.php, Subs-Members.php)
* Moved the JumpTo text from the basic HTML source to the script.js file, where at least it's cached. Only saves a few bytes per page, but why wouldn't I want to..? Plus, hey, it's a free fix for infinite scrolling... (index.template.php, script.js)
2462
The Pub / Re: Infinite Scroll
« on October 4th, 2013, 03:55 PM »
Well, I'm just surprised you're getting that viewport size. In non-Wireless, normally it shouldn't adapt to your screen, it's got a set size.
Anyway, infinite scrolling is available in Wireless, so it shouldn't be a problem...
I've finally stabilized my local codebase for inf scrolling, BTW.
And it's super-cool now. :) Will try to commit soon, but I've got many changes to sort through, as often.
Anyway, infinite scrolling is available in Wireless, so it shouldn't be a problem...
I've finally stabilized my local codebase for inf scrolling, BTW.
And it's super-cool now. :) Will try to commit soon, but I've got many changes to sort through, as often.
2463
The Pub / Re: Infinite Scroll
« on October 4th, 2013, 07:29 AM »
Unless you changed the skin manually.
Why didn't you ever report the bugs of a severely broken skin, otherwise? I assume you would have..?
Why didn't you ever report the bugs of a severely broken skin, otherwise? I assume you would have..?
2465
The Pub / Re: Infinite Scroll
« on October 3rd, 2013, 05:59 PM »
It's not my local version, so I'm guessing you completely missed on this feature before, right..? ;)
Also, normally Wireless has a Like button, actually I'm in Wireless right now... :^^;:
Okay, today I've been rewriting it again, attempting to solve its main drawback, i.e. the sometimes long Ajax loading times. Instead of wheeling several times past the page end, I'm rewriting to adopt a more 'classic' method, i.e. prefetching the page while you're reading the posts, but with a trick to, hopefully, keep usability at its best:
- first of all, Wedge will determine if you've been scrolling past a certain point (3 pages before the end of the page).
- if yes, it'll prefetch the page. Mark the topic as read up to the post BEFORE the new page being prefetched. (Meaning, if you come back later through non-infinite scrolling, you'll be redirected to the last 'safe' page that we know you've been through, it's important to me...)
- then, it'll test whether you've attempted to scroll past the end. I'm no longer waiting for an extra wheel roll, because at this point, it's likely that the page is already in cache, so there's no reason not to show it. Also, I'm not showing it as soon as it's available to show, because I want to give users the opportunity to interact with the footer.
- if the page newly shown is the last in the topic, mark the topic as read.
- I'm considering showing a 'Click for more posts' banner at the bottom of the page when more posts are available to show; this would make it possible to show the next page without ever 'knowing' that you have to scroll past the end, I guess...
Unfortunately, it's not working right now, I'm having some difficulties, but I've been fighting difficulties all day, and I've made progress, so... Whatever!
Also, normally Wireless has a Like button, actually I'm in Wireless right now... :^^;:
Okay, today I've been rewriting it again, attempting to solve its main drawback, i.e. the sometimes long Ajax loading times. Instead of wheeling several times past the page end, I'm rewriting to adopt a more 'classic' method, i.e. prefetching the page while you're reading the posts, but with a trick to, hopefully, keep usability at its best:
- first of all, Wedge will determine if you've been scrolling past a certain point (3 pages before the end of the page).
- if yes, it'll prefetch the page. Mark the topic as read up to the post BEFORE the new page being prefetched. (Meaning, if you come back later through non-infinite scrolling, you'll be redirected to the last 'safe' page that we know you've been through, it's important to me...)
- then, it'll test whether you've attempted to scroll past the end. I'm no longer waiting for an extra wheel roll, because at this point, it's likely that the page is already in cache, so there's no reason not to show it. Also, I'm not showing it as soon as it's available to show, because I want to give users the opportunity to interact with the footer.
- if the page newly shown is the last in the topic, mark the topic as read.
- I'm considering showing a 'Click for more posts' banner at the bottom of the page when more posts are available to show; this would make it possible to show the next page without ever 'knowing' that you have to scroll past the end, I guess...
Unfortunately, it's not working right now, I'm having some difficulties, but I've been fighting difficulties all day, and I've made progress, so... Whatever!
2467
Features / Re: AJAX Quick Reply
« on October 3rd, 2013, 01:23 AM »
I disabled it because of the undefined constant. It's only temporary.
Do you have the problem, locally..?
Do you have the problem, locally..?
2468
The Pub / Re: Infinite Scroll
« on October 3rd, 2013, 12:50 AM »
Can't believe it, I actually fixed my test page with broken embeds and all that crap...!!
I started going into complicated stuff, for several DAYS of course, and then I fixed it all by reverting all of my changes, and doing a simple test.
I'd completely forgotten that swfobjects was hard to load from an Ajax page -- and ultimately, this is what an infinite scroller is; but internally, Wedge considers infinite scroll pages as 'normal' pages, so that it gets the proper rendering. That's a bit of a wrong thing to do, especially because in some places, infscroll needs the Ajax code path (e.g. embeds), and in others, it needs the non-Ajax code path. Very funny, really...
So, I just double-checked, and now all Flash embeds should properly work in infinite scroll pages, and thus NOT stop the new page from loading, and my friends, that is a frigging victory!
I also rewrote many things in the infscroll process, so that it sends MUCH less data per request; you can save up to 80% of the page data, if there's not much content in the next page. Otherwise, it's between 20% to 50%. Also executes a bit faster.
Tomorrow, I'm gonna give a try at pre-fetching the next page while marking the previous page (not the current page) as read, to ensure that one can safely stop reading through an infinitely scrolling page, and later come back through an Unread link, and find themselves on the page they were currently viewing at that point (i.e. last 15 posts in the infinite scroll page), which is cool. Well, I'm not very familiar with the markread code, so every little victory like this is good to me.
Phew... Then, it means I can keep the current implementation. And that it's going to become much more useful. :)
I started going into complicated stuff, for several DAYS of course, and then I fixed it all by reverting all of my changes, and doing a simple test.
I'd completely forgotten that swfobjects was hard to load from an Ajax page -- and ultimately, this is what an infinite scroller is; but internally, Wedge considers infinite scroll pages as 'normal' pages, so that it gets the proper rendering. That's a bit of a wrong thing to do, especially because in some places, infscroll needs the Ajax code path (e.g. embeds), and in others, it needs the non-Ajax code path. Very funny, really...
So, I just double-checked, and now all Flash embeds should properly work in infinite scroll pages, and thus NOT stop the new page from loading, and my friends, that is a frigging victory!
I also rewrote many things in the infscroll process, so that it sends MUCH less data per request; you can save up to 80% of the page data, if there's not much content in the next page. Otherwise, it's between 20% to 50%. Also executes a bit faster.
Tomorrow, I'm gonna give a try at pre-fetching the next page while marking the previous page (not the current page) as read, to ensure that one can safely stop reading through an infinitely scrolling page, and later come back through an Unread link, and find themselves on the page they were currently viewing at that point (i.e. last 15 posts in the infinite scroll page), which is cool. Well, I'm not very familiar with the markread code, so every little victory like this is good to me.
Phew... Then, it means I can keep the current implementation. And that it's going to become much more useful. :)
2469
The Pub / Re: Infinite Scroll
« on October 1st, 2013, 11:38 PM »
Got it working a bit better... Well, to be honest, right now on wedge.org, it's working perfectly fine. The updated version is pretty much the same... In fact, they both have the same limitation: if the new page has JS errors in it, it screw up everything. And since I'm doing half of my tests on a page that specifically has JS errors (a buggy video embedding, apparently), I consistently see THAT problem.
I think I've found a solution for the duplicate thingy, though, but mostly, it'll be down to the plugin authors to see to it that their code can execute twice without issues.
I think I've found a solution for the duplicate thingy, though, but mostly, it'll be down to the plugin authors to see to it that their code can execute twice without issues.
2470
The Pub / Re: Infinite Scroll
« on October 1st, 2013, 12:45 AM »
Another day working on a potential infinite scrolling rewrite-- another failure. Yesterday, tried to do something with the Shadow DOM. Today, it was with createHTMLDocument(), and executing scripts in a parallel document. Yes, another failure... The new script tags still execute globally the moment the additional document is added to the main DOM. Ah, well. I thought I was onto something, really...!
2471
Off-topic / Re: Is Wordpress actually Most SEO CMS?
« on September 30th, 2013, 10:08 PM »
Agreed.
My technique for seo in Wedge is to simply use as little markup as possible and use HTML tags if it makes sense.
Less markup = better signal to noise ratio in a page. I'm sure Google likes that, but I'm no expert...
My technique for seo in Wedge is to simply use as little markup as possible and use HTML tags if it makes sense.
Less markup = better signal to noise ratio in a page. I'm sure Google likes that, but I'm no expert...
2472
Off-topic / Re: CSS issue
« on September 30th, 2013, 10:05 PM »
Doable but only by rewriting the header to be the relatively positioned div and then setting a hardcoded top for both the menu and sub menus.
Honestly, I would rely on JS for best results, but...
Honestly, I would rely on JS for best results, but...
2473
The Pub / Re: Infinite Scroll
« on September 29th, 2013, 08:04 PM »I faced the same annoyances :( infinitescroll is nice and dandy but it is really a pain in the posterior.
I used the jquery plugin
I couldn't get a fine and stable code for scrolling events, yes jQuery has .scroll() and I can get if the user has reached the bottom of a page, however, it was very unstable (if the user stays at the bottom the event gets fire constantly) so I decided to use a "load more" button.
I must admit, I'm a mouse wheel freak... I tend to roll it everywhere, including at the end of a page, so it was a no-brainer for me. The counterpart, though, is that I can't decide whether to use the system to just load the next page the 'regular' way, because the current solution at least allows me to keep reading the last post in the page, even if I'm wheeling a bit too much.
Another issue was handling all the HTML, I had 2 options, sent the entire data plus HTML as a json object or just send the pure data and have all the HTML either created on-the-fly or as an empty shell on the template itself, I decided to just sent the already constructed HTML as a json object and then just use .append() on an empty <ul> created on-the-fly by jQuery.
I didn't want to have multiple template structures so I took the message HTML, isolated it on a single function with all the data (content, poster, time, etc) passed as a param and thats the only template I use for every place where I show a message, it is a little hackish because in the same function I can either return the structured HTML or just print it, depending on where exactly I'm using that template function, my solution was to use a var and at the end simple decide what to do, return it or print it, not nice but it works.
I'm trying to figure out a 'different way', but it's hard. Something like, take all functions that knowingly modify messages (layout, contents...), and have them declare themselves to a special hook that will call them again when new posts are inserted. But I need to figure out a clean way to do that. And I don't even know if it's viable.
Either way, it probably won't be ready for v1.0... In fact, I'm likely to keep things as they are for now, because it 'mostly works', and I'll just fix my existing broken code (i.e. duplicate HTML.) I think that the face value of having this nice infinite scrolling effect is important for Wedge to gain some momentum among the SMF community, and if removed later and replaced with a plugin, it'll have less visibility and I'll be sad about it. (I DID spend a lot of time on this...)
I also faced the duplicate DOM elements, in my case it wasn't that much of an issue since I don't handle that many features and options, my solution was handling all JS events using jQuery(document).on() to differentiate between events I use the ID in the ID attribute so:
But I recon, the amount of DOM elements I manage is extremely low and this approach wouldn't work on handling forum messages.
2474
Features / Re: AJAX Quick Reply
« on September 29th, 2013, 05:10 PM »NOW you tell me!Quote Wedge's infinite scrolling code... Which isn't freely available to use
But I don't care if it's core or not.
2475
The Pub / Re: Infinite Scroll
« on September 29th, 2013, 05:09 PM »Infinite scrolling looks real nice, but the difference between the present version and the one just loading the next page on further scrolling is visible for a second or so.
Okay, regarding the use of an iframe. I should have remembered that... The problem with iframes is two-fold:
- if I just want to load the next page into an iframe and have it take the correct height etc, it'll still run its JavaScript inside of the frame, and thus, a popup animation will take place inside of it, not inside of the main page.
- if I want to 'import' the HTML from within the iframe towards the main page, the JavaScript will STILL execute within the iframe, or, if the iframe is removed consequently, it won't execute at all.
I tried to find a proper way to 'move' the scripts, but the current solution has been doing that, and it's what I wanted to avoid: any changes to the DOM affect the entire page, not just the new stuff...
And doing a trick such as overriding jQuery.fn.init to always add the new content's div as the 'context' variable doesn't seem to work. It didn't back when I first thought of it last month, and it still doesn't.
The big, big issue with infinite scrolling, is really that it's tailored to one of two situations:
- the new content is really, really simple, and we are 100% sure there's not (much) JavaScript in it; making it possible to just show it without dealing with JS...
- or on the contrary, it's very complicated, but the whole website is a 'web app' in style, that is, the HTML is only a placeholder to run Ajax queries, and show them after applying some magic to the results. For instance, Backbone.js allows for this kind of thing.
Wedge is not the former, and as for the latter, it would require passing all message-related functions to a single pass-through function that would then reapply its modifications on demand. Basically, while it's DOABLE, it's not realistic. It would put far too much pressure on plugin developers and themers, and I don't want that.
I'm considering, though, the possibility of keeping the current code but as a plugin; i.e., it's the responsibility of the webmaster to determine whether they want the cool effect, and whether they're ready to accept they'll have to disable some other plugins that may conflict with it.