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
6781
Features / Re: New revs - Public comments
« on December 28th, 2011, 01:42 PM »
So... I made a quick benchmark with script positioning, and here are my (non-scientific) results:
- all browsers pretty much execute the stuff in the same time. So the time before .load() is available remains the same, whatever the method used.
- IE6 benefits from having scripts at the bottom, because it's so slow at executing JS, and running jQuery + script in the head slows it down by a second or two... :( So, I've disabled it for IE6, it'll always execute below.
- IE7, IE8 and IE9 give similar results in both situations.
- Same for Chrome, Firefox 3 and Safari.
- Opera looks clearly better with the scripts at the top, plus it probably fixes the occasional FOUC I would get (only in admin pages). So it's definitely staying this way for Opera (i.e. always at the bottom, except if user is logged in and came recently.)
Interestingly, the YSlow tool recommends having the scripts at the bottom -- but wherever I have them, it still gives me an A ranking for that category. It probably 'understands' that some scripts can't be put at the bottom (which is actually completely untrue, given what I managed to do with SMF/Wedge, but whatever.)
- all browsers pretty much execute the stuff in the same time. So the time before .load() is available remains the same, whatever the method used.
- IE6 benefits from having scripts at the bottom, because it's so slow at executing JS, and running jQuery + script in the head slows it down by a second or two... :( So, I've disabled it for IE6, it'll always execute below.
- IE7, IE8 and IE9 give similar results in both situations.
- Same for Chrome, Firefox 3 and Safari.
- Opera looks clearly better with the scripts at the top, plus it probably fixes the occasional FOUC I would get (only in admin pages). So it's definitely staying this way for Opera (i.e. always at the bottom, except if user is logged in and came recently.)
Interestingly, the YSlow tool recommends having the scripts at the bottom -- but wherever I have them, it still gives me an A ranking for that category. It probably 'understands' that some scripts can't be put at the bottom (which is actually completely untrue, given what I managed to do with SMF/Wedge, but whatever.)
6782
Features / Re: New revs - Public comments
« on December 28th, 2011, 12:35 PM »
Yes, it does -- $post_errors can still contain arrays as filled in by Class-Editor.php with the 'mismatched_tags' type.
However, there IS an error indeed -- missing_tags is no longer a valid error, which I forgot to remove from that. After thinking it through, I decided to merge the methods for mismatched_tags and long_message, and thus I rewrote every area that filled in long_message, and put it into a sub-array instead. This makes for a cleaner code. (Hopefully it'll work... :P)
As for $here, does that still mean there's a bug for me to fix...?
However, there IS an error indeed -- missing_tags is no longer a valid error, which I forgot to remove from that. After thinking it through, I decided to merge the methods for mismatched_tags and long_message, and thus I rewrote every area that filled in long_message, and put it into a sub-array instead. This makes for a cleaner code. (Hopefully it'll work... :P)
As for $here, does that still mean there's a bug for me to fix...?
6783
Features / Re: New revs
« on December 28th, 2011, 12:08 PM »
rev 1226
(2 files, 3kb)
+ Move jQuery and script.js to the *top* of the page if the user is logged in and was seen less than 10 minutes ago, making it likely their scripts are already cached and the page will actually finish loading faster. Needs some further benchmarking, but as of now this is one of those ideas that seem so incredibly simple, and yet no one seems to have ever considered it before, so it's probably the genius at work... (Or the village idiot, more likely.) (index.template.php)
! $dd was already part of $sb, no need to re-insert it at open time... Current size is thus 2071 bytes. Still working on the custom scrollbar and not making much progress... Yep, definitely village idiot material here. (sbox.js)
(2 files, 3kb)
+ Move jQuery and script.js to the *top* of the page if the user is logged in and was seen less than 10 minutes ago, making it likely their scripts are already cached and the page will actually finish loading faster. Needs some further benchmarking, but as of now this is one of those ideas that seem so incredibly simple, and yet no one seems to have ever considered it before, so it's probably the genius at work... (Or the village idiot, more likely.) (index.template.php)
! $dd was already part of $sb, no need to re-insert it at open time... Current size is thus 2071 bytes. Still working on the custom scrollbar and not making much progress... Yep, definitely village idiot material here. (sbox.js)
6784
Features / Re: New revs - Public comments
« on December 28th, 2011, 10:44 AM »
I don't understand your bumped question. Line numbers and files please?
$here spits out the relative path from the cache folder to wherever your skin file is (for images in the same folder). Iirc because I'm on my iPod.
$here spits out the relative path from the cache folder to wherever your skin file is (for images in the same folder). Iirc because I'm on my iPod.
6785
Features / Re: Selectbox
« on December 27th, 2011, 11:34 PM »
Well... Pretty quiet today innit?
After doing some tests with HeadJS (1.4kb minified and gzipped), it suddenly hit me... There's ANOTHER way of doing things!
It's not perfect, but here it is:
- While showing the head area, determine the *last login* time ($user_info['last_login']) and, if it's less than 10 minutes ago, assume that the user already has the script files cached in their browser cache.
- If cached, then run theme_base_js(1) right after theme_base_css() in the head.
- If cached, then at the end of the page, call $('select').sb() right after the inline JS has been printed (could even do that BEFORE any final JS really....), because the original call would have returned nothing at all (since the HTML was not printed out yet.)
- If not cached, then instead of the sb() call, simply show theme_base_js().
I tested it under Firefox 3.6 (my current testbed for Firefox, don't mind me), and the difference is very subtle, as in both cases it pretty much loads the select boxes immediately. It's done flawlessly in head mode though.
And of course, I also tested under Opera and while it still has issues showing select boxes immediately, it's much faster -- original had me wait for about one second on a typical page, while the new one takes about a tenth of a second. Only issue is that when I repeatedly reload the page (on my local install), the page stays entirely white for a few tenths of a second, and then it shows the page and almost immediately prints the new select box. I don't know which is best, honestly. I guess in a REGULAR situation (i.e. forum user), the second solution is better -- it probably loads (overall) a bit faster, but I guess it'll take a JS benchmark to make the difference.
Any opinions on this method?
After doing some tests with HeadJS (1.4kb minified and gzipped), it suddenly hit me... There's ANOTHER way of doing things!
It's not perfect, but here it is:
- While showing the head area, determine the *last login* time ($user_info['last_login']) and, if it's less than 10 minutes ago, assume that the user already has the script files cached in their browser cache.
- If cached, then run theme_base_js(1) right after theme_base_css() in the head.
- If cached, then at the end of the page, call $('select').sb() right after the inline JS has been printed (could even do that BEFORE any final JS really....), because the original call would have returned nothing at all (since the HTML was not printed out yet.)
- If not cached, then instead of the sb() call, simply show theme_base_js().
I tested it under Firefox 3.6 (my current testbed for Firefox, don't mind me), and the difference is very subtle, as in both cases it pretty much loads the select boxes immediately. It's done flawlessly in head mode though.
And of course, I also tested under Opera and while it still has issues showing select boxes immediately, it's much faster -- original had me wait for about one second on a typical page, while the new one takes about a tenth of a second. Only issue is that when I repeatedly reload the page (on my local install), the page stays entirely white for a few tenths of a second, and then it shows the page and almost immediately prints the new select box. I don't know which is best, honestly. I guess in a REGULAR situation (i.e. forum user), the second solution is better -- it probably loads (overall) a bit faster, but I guess it'll take a JS benchmark to make the difference.
Any opinions on this method?
6786
The Pub / Re: Logo Madness
« on December 27th, 2011, 08:12 PM »
Maybe something like this...? Or maybe not. Applied a small 3D effect to the logo... (and now I just realized it looks a bit like an animal head with its tongue out :lol:)
(See end of the post.)
Quote from Spr1te on December 27th, 2011, 06:57 AM But, interestingly, I think it's a very nice feature... I don't like things being so clean, but never could find the perfect balance between clean and rusty.
I guess it also reminds me of Bloc's first logo attempt, with a small 'cut' in the first 'e'.Quote ...Which won't last forever (although I'm considering making a custom Wedge skin that will try to emulate the best features of Wedge.org's current theme.)Quote The 'we' is either 'Pete and I', or 'Communities' as built with Wedge. It's not supposed to represent any links to SMF. ;)Quote That's a possibility. There's also the slogan, though... ;)Quote But isn't it deformed, here?
(See end of the post.)
Posted: December 27th, 2011, 08:07 PM
The blemish you refer to occurred during conversion from original artwork to an alternative format. A minor fix.
I guess it also reminds me of Bloc's first logo attempt, with a small 'cut' in the first 'e'.
I chose slightly darker coloring to compliment the boards existing scheme particularly,
Anyway, as for concepts I deliberately kept it close to the final as mentioned. You will notice theres slightly more subtle difference in coloring in "we dge" but its still visible, I also wanted to emphasise Wedge is a forked version of SMF....as in WE and them or EDGE.
As for my indulgence in "Forum" subscript, I felt a more abbreviated approach was needed and to highlight the fact that it is exactly what this site stands for..."Forum Software"...Its more balanced in terms of logo presentation and gets to the point.
Ah the font..Eras - I find it pleasing to the eye and as professional a font as Helvetica, Arial and other industry standards.
6787
Features / Re: Selectbox
« on December 27th, 2011, 08:05 PM »
Also... What do you think of my method to avoid the FOUC on select boxes?
I like it, although it can be argued that if JavaScript is disabled, there's no way to see the select boxes at all.
But I'm also considering (again) the possibility of having jQuery and our scripts loaded ASAP, that is, asynchronously from the page header... I'm not exactly sure it'd be worth it, but anything that could help is welcome.
Thing is, it seems that the tech evolved since I began working on Wedge, so various async loading libraries have popped up in the last year, including Control.js which apparently would be the best, and has been forked by others, although I don't know which fork would be best. What I know, though, is that Control.js is 2KB gzipped and minified, and it's a bit much for my taste... I suppose I could be 'wrong', because after all, once it's loaded and cached, it's all good. I found another (jQl), made by a Frenchie, aiming to specifically async-load jQuery, so I like that, plus it's very short (700 bytes minified and gzipped after applying a few optimizations on it). I have yet to test it, though...
Anyway -- I like these ideas but I don't know if it's worth implementing all of this into Wedge. What do you think? (and it's probably not the best topic to ask about that so I'll probably move or split this post at some point...)
I like it, although it can be argued that if JavaScript is disabled, there's no way to see the select boxes at all.
But I'm also considering (again) the possibility of having jQuery and our scripts loaded ASAP, that is, asynchronously from the page header... I'm not exactly sure it'd be worth it, but anything that could help is welcome.
Thing is, it seems that the tech evolved since I began working on Wedge, so various async loading libraries have popped up in the last year, including Control.js which apparently would be the best, and has been forked by others, although I don't know which fork would be best. What I know, though, is that Control.js is 2KB gzipped and minified, and it's a bit much for my taste... I suppose I could be 'wrong', because after all, once it's loaded and cached, it's all good. I found another (jQl), made by a Frenchie, aiming to specifically async-load jQuery, so I like that, plus it's very short (700 bytes minified and gzipped after applying a few optimizations on it). I have yet to test it, though...
Anyway -- I like these ideas but I don't know if it's worth implementing all of this into Wedge. What do you think? (and it's probably not the best topic to ask about that so I'll probably move or split this post at some point...)
6788
Features / Re: New revs
« on December 27th, 2011, 01:58 PM »
rev 1225
(5 files, 4kb)
! Fixed Welcome page to show Modify/Reply buttons in thoughts area when clicking a thought (as opposed to simply clicking the thought's author link, which was totally counter-intuitive... Thank Apple for their strange handling of hovers.) (Welcome.php)
+ A custom select box's display area should now inherit all of its original's events, effectively dealing with onclick etc without us having to worry about them. This also forced me to add 16 bytes to the .data("eve") retrieval method on every page (because of an IE bug, who else?), although if there are more than 8 event calls on the page, which is quite likely, it'll actually make it shorter. (Subs-Template.php, sbox.js)
* Custom select boxes will no longer trigger their original's events willingly. This is to avoid triggering the select box behavior on my iPod, which although very usable, is also unable to cope with HTML and multi-line elements unlike Wedge's. (sbox.js)
* Optimized select box animation from last commit for size (a bit). Current gzipped minified size is 2074 bytes, which is still quite good! (sbox.js)
* Minor CSS cleanup, including fixing select boxes when inside cat/title headers. (index.css, sections.css)
(5 files, 4kb)
! Fixed Welcome page to show Modify/Reply buttons in thoughts area when clicking a thought (as opposed to simply clicking the thought's author link, which was totally counter-intuitive... Thank Apple for their strange handling of hovers.) (Welcome.php)
+ A custom select box's display area should now inherit all of its original's events, effectively dealing with onclick etc without us having to worry about them. This also forced me to add 16 bytes to the .data("eve") retrieval method on every page (because of an IE bug, who else?), although if there are more than 8 event calls on the page, which is quite likely, it'll actually make it shorter. (Subs-Template.php, sbox.js)
* Custom select boxes will no longer trigger their original's events willingly. This is to avoid triggering the select box behavior on my iPod, which although very usable, is also unable to cope with HTML and multi-line elements unlike Wedge's. (sbox.js)
* Optimized select box animation from last commit for size (a bit). Current gzipped minified size is 2074 bytes, which is still quite good! (sbox.js)
* Minor CSS cleanup, including fixing select boxes when inside cat/title headers. (index.css, sections.css)
6789
Features / Re: Selectbox
« on December 27th, 2011, 10:45 AM »
Unfortunately it means that if all entries have a prefix then it won't work well. Like "--->" you know. Unless I add a data-prefix entry to have the code skip it...
6790
Features / Re: Fixing mismatched BBCode
« on December 27th, 2011, 10:43 AM »
I think our current implementation works best.
But I'd like to ensure the error message path is used for quick edit as well. Firefox does it already iirc. At least on my custom noisen code. I need to remember working on that.
But I'd like to ensure the error message path is used for quick edit as well. Firefox does it already iirc. At least on my custom noisen code. I need to remember working on that.
6791
Features / Re: Selectbox
« on December 27th, 2011, 09:39 AM »
I don't think so? I think opera only goes for first letters. How would you do it otherwise?
6792
Features / Re: Fixing mismatched BBCode
« on December 27th, 2011, 09:37 AM »
You mean you'd like to see some pseudo code on how I did it? :p
6793
Features / Re: New revs
« on December 26th, 2011, 11:37 PM »
rev 1224
(3 files, 3kb)
+ Added a very nice little animation to fixed select boxes when an item is clicked. Definitely adds to it! (sbox.js)
* Now with pixel-perfect positioning of select box arrow button next to display area. (sbox.js, index.css)
! Went through all main browsers to test the keyboard accessibility of the select box. Turns out only Opera, Firefox and IE9 (I think) were behaving nicely, so I had to fix it for IE 6-8 and Webkit by conditionally moving the event to keydown. Grmpf. (sbox.js)
! Icon selector in the Post template wasn't using a tabindex, and because other elements were using it, it wouldn't be selected when cycling through elements with the Tab key. (Post.template.php)
(3 files, 3kb)
+ Added a very nice little animation to fixed select boxes when an item is clicked. Definitely adds to it! (sbox.js)
* Now with pixel-perfect positioning of select box arrow button next to display area. (sbox.js, index.css)
! Went through all main browsers to test the keyboard accessibility of the select box. Turns out only Opera, Firefox and IE9 (I think) were behaving nicely, so I had to fix it for IE 6-8 and Webkit by conditionally moving the event to keydown. Grmpf. (sbox.js)
! Icon selector in the Post template wasn't using a tabindex, and because other elements were using it, it wouldn't be selected when cycling through elements with the Tab key. (Post.template.php)
6794
Off-topic / Re: Boycott GoDaddy
« on December 26th, 2011, 01:23 PM »
My two registrars are just as cheap as GoDaddy, and they're super-cool. (Well, one of them is not exactly cheaper... But it's very reliable as a company, and they're open source champions. So, some of my domains are at their place.)
6795
The Pub / Re: Logo Madness
« on December 26th, 2011, 01:21 PM »
Well... Interesting colors, surely![1] The placement, too. Is that a glitch in the lower corner?
Overall, I like it. It's nice to see something that keeps in line with my own concept, and tries to explore slight variations that I didn't consider myself.
The software is just named Wedge, without 'Forums' or anything. The simplicity is as desired. And yes, it's easier to make an eye-catching logo when you have two words, which is why 'wedge' itself puts the emphasis on 'we', as if it was made of two words -- we and dge. Err, sorry, 'we' and 'edge'.
Not convinced with the font, though... It looks like a deformed version of a simpler font face. As you may be aware if you've followed this topic, I've always been quite typography-centric and these last few months it's even become something of an obsession -- especially with the logo, and the difficulties I'm meeting when trying to determine whether Wedge should sport a web-aware font by default, or go for a custom @font-face. (And even then -- my fave web-aware font is Segoe UI but it's not available on 50%+ computers, and my second favorite is Arial but the aliased versions suck. Then again, anything without anti-aliasing sucks, too...)
Overall, I like it. It's nice to see something that keeps in line with my own concept, and tries to explore slight variations that I didn't consider myself.
The software is just named Wedge, without 'Forums' or anything. The simplicity is as desired. And yes, it's easier to make an eye-catching logo when you have two words, which is why 'wedge' itself puts the emphasis on 'we', as if it was made of two words -- we and dge. Err, sorry, 'we' and 'edge'.
Not convinced with the font, though... It looks like a deformed version of a simpler font face. As you may be aware if you've followed this topic, I've always been quite typography-centric and these last few months it's even become something of an obsession -- especially with the logo, and the difficulties I'm meeting when trying to determine whether Wedge should sport a web-aware font by default, or go for a custom @font-face. (And even then -- my fave web-aware font is Segoe UI but it's not available on 50%+ computers, and my second favorite is Arial but the aliased versions suck. Then again, anything without anti-aliasing sucks, too...)
| 1. | Reminded me a bit of the Logitech logo. After double-checking, though, it's only loosely related. |