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
3886
Archived fixes / Re: Reply Error with Chrome
« on January 18th, 2013, 06:14 PM »
Which is both a good reason to switch to SCE and an excellent reason not to :P
3887
Features / Re: Template edits
« on January 18th, 2013, 06:13 PM »
Oh... I don't know. I'm sure it's not that complicated. I wrote most of the needed code I reckon.
For instance, the skeleton system has no problem running a sub-template several times, like the linktree code. It just needs two different arguments -- <linktree> and <linktree:bottom> in our case. There's nothing preventing us from having a <message:0> entry where the message numbers are indicated in the skeleton.
Of course, this would all have to be done through wetem::calls rather than skin.xml editing because it's a skeleton that needs injecting inside the main area of a single template. But it's all done I think...
Haven't had time to look into it, though. I'm hungry.
What do you think? (About this. Not that I'm hungry. You silly.)
For instance, the skeleton system has no problem running a sub-template several times, like the linktree code. It just needs two different arguments -- <linktree> and <linktree:bottom> in our case. There's nothing preventing us from having a <message:0> entry where the message numbers are indicated in the skeleton.
Of course, this would all have to be done through wetem::calls rather than skin.xml editing because it's a skeleton that needs injecting inside the main area of a single template. But it's all done I think...
Haven't had time to look into it, though. I'm hungry.
What do you think? (About this. Not that I'm hungry. You silly.)
3888
Archived fixes / Re: Reply Error with Chrome
« on January 18th, 2013, 05:51 PM »
Hmm... So it means SCE has a built-in JavaScript convert tool for HTML to BBCode..? (Meaning it doesn't need to rely on Ajax for Wysiwyg switching... Although it also means it's less flexible!)
3889
Features / Re: New revs
« on January 18th, 2013, 05:50 PM »
rev 1856
(16 files, 7kb)
+ Added HTTPS support for CDN-based jQuery includes. This will prevent IE (and some other browsers) from shouting at you if your $scripturl has https:// in it. (Load.php, Subs-Cache.php)
* So... I went to see my doctor, and he diagnosed a rare case of bytophobia. He said it can't be cured. He also added that .slice() is one byte shorter than .substr() and behaves similarly to .substring() but with support for negative indices, so he recommended that I'd focus on turning all of my substr calls to slice. This saved quite a lot of gzipped bytes in a few files. Although I'm starting to wonder if he really was an actual doctor... (captcha.js, editor-func.js, editor.js, ie6hover.js, mediadmin.js, player.js, post.js, respond.js, script.js, spellcheck.js, stats.js, suggest.js, topic.js, up.js)
@ For those interested, I also saved bytes by: (1) removing txlen1 and txlen2 variables from the editor (they were introduced as an Opera fix, which is no longer needed, and I forgot to remove them entirely), (2) removing an unneeded filename.length in post.js, (3) turning a very silly (also in SMF!) sText.substr(0, aResult.index).length) into just aResult.index, (4) turning a str.substr(x, 1) into str[x] in captcha.js, and (5) removing an unneeded file.name.length in up.js. I'm surprised that 'this' in $.fn.mime is correctly typed as a string instead of an array when calling .slice() on it. Eh, you never know... It still saves one byte doing that, so it's definitely worth the risk. Ah ah.
:edit: Fixed wrong HTML in this post.
(16 files, 7kb)
+ Added HTTPS support for CDN-based jQuery includes. This will prevent IE (and some other browsers) from shouting at you if your $scripturl has https:// in it. (Load.php, Subs-Cache.php)
* So... I went to see my doctor, and he diagnosed a rare case of bytophobia. He said it can't be cured. He also added that .slice() is one byte shorter than .substr() and behaves similarly to .substring() but with support for negative indices, so he recommended that I'd focus on turning all of my substr calls to slice. This saved quite a lot of gzipped bytes in a few files. Although I'm starting to wonder if he really was an actual doctor... (captcha.js, editor-func.js, editor.js, ie6hover.js, mediadmin.js, player.js, post.js, respond.js, script.js, spellcheck.js, stats.js, suggest.js, topic.js, up.js)
@ For those interested, I also saved bytes by: (1) removing txlen1 and txlen2 variables from the editor (they were introduced as an Opera fix, which is no longer needed, and I forgot to remove them entirely), (2) removing an unneeded filename.length in post.js, (3) turning a very silly (also in SMF!) sText.substr(0, aResult.index).length) into just aResult.index, (4) turning a str.substr(x, 1) into str[x] in captcha.js, and (5) removing an unneeded file.name.length in up.js. I'm surprised that 'this' in $.fn.mime is correctly typed as a string instead of an array when calling .slice() on it. Eh, you never know... It still saves one byte doing that, so it's definitely worth the risk. Ah ah.
:edit: Fixed wrong HTML in this post.
3890
Features: Forward thinking / Re: jQuery support
« on January 18th, 2013, 05:33 PM »
SMF 2.0 = 6.5 MB
SMF 2.1 = 7.2 MB (latest)
Wedge = 11.4 MB (latest)
Also...
I was wondering... Should we use //urls instead of http://urls? This is supported by all browsers, the only situation where it doesn't work is if you're browsing via file://. Other than that, it saves bytes and all. But ultimately, the best way to save bytes is to also do the same on all other URLs... And that's where I'm starting to wonder and wander...
So, yeah, I updated the jQuery URLs to use the https protocol if the current website is running on https.
At least THAT is done. :P
SMF 2.1 = 7.2 MB (latest)
Wedge = 11.4 MB (latest)
Also...
I was wondering... Should we use //urls instead of http://urls? This is supported by all browsers, the only situation where it doesn't work is if you're browsing via file://. Other than that, it saves bytes and all. But ultimately, the best way to save bytes is to also do the same on all other URLs... And that's where I'm starting to wonder and wander...
So, yeah, I updated the jQuery URLs to use the https protocol if the current website is running on https.
At least THAT is done. :P
3891
Archived fixes / Re: Viewing an unread media item does not mark it as read
« on January 18th, 2013, 05:29 PM »
So... Went to the Unseen page, clicked on an image thumbnail, it launched the preview (not the full image, mind you), reloaded page, had everything except for that item.
So yeah, it's working I'm afraid...!
So yeah, it's working I'm afraid...!
3892
Features / Re: Template edits
« on January 18th, 2013, 05:27 PM »
I'm sure there are multiple ways to do this... There should be a hook with the message content somewhere, so you might be able to simply add something to the body that says it's the OP...
If you want to add something somewhere else, I guess we'll have to add hooks for per-post templating. But that would be a good thing, of course. Not sure how to deal with themes that wouldn't follow them, though... (Their loss?)
Or maybe something could be done at template rendering time... I remember I wanted to add a mini-template just for posts, so that you could add a template_after or template_before etc that would apply to EACH post... I don't think it's possible for now.
If you want to add something somewhere else, I guess we'll have to add hooks for per-post templating. But that would be a good thing, of course. Not sure how to deal with themes that wouldn't follow them, though... (Their loss?)
Or maybe something could be done at template rendering time... I remember I wanted to add a mini-template just for posts, so that you could add a template_after or template_before etc that would apply to EACH post... I don't think it's possible for now.
3893
Features / Re: New revs
« on January 18th, 2013, 01:20 PM »
rev 1855
(6 files, 4kb) (it seems I'm subscribed to 4kb commits these days...?!)
* Improved JS URL shortener: ampersands are now properly cut (through a php_unhtmlspecialchars call), increased maximum length to the usual default of 50 chars instead of 30 (it was really just for my tests), and if a container is too narrow to show even 50 chars, Wedge now inserts a wbr tag after the ellipsis, that allows for the URL to be shown over two lines. And it doesn't take any additional byte to add all of this, yay. (script.js)
! Fixed Wuthering linktree in IE7. It needs a mixin (rather than a base) because of the parent skin. Soon, I'll start working on moving Wuthering and Warm to the root. Should be simpler to manage in the end... Child skins really should be there only to change a few lines, not create completely new skins. Just because I could doesn't mean I should have. I need to see a doctor. (Wuthering/extra.css)
! Typo (number_content instead of number_context). (PersonalMessage.php)
* Translation. (ManageMaintenance.french.php, PersonalMessage.french.php)
* Saving a gzipped byte by reordering two lines. Really. I need a doctor. Now. (index.css)
(6 files, 4kb) (it seems I'm subscribed to 4kb commits these days...?!)
* Improved JS URL shortener: ampersands are now properly cut (through a php_unhtmlspecialchars call), increased maximum length to the usual default of 50 chars instead of 30 (it was really just for my tests), and if a container is too narrow to show even 50 chars, Wedge now inserts a wbr tag after the ellipsis, that allows for the URL to be shown over two lines. And it doesn't take any additional byte to add all of this, yay. (script.js)
! Fixed Wuthering linktree in IE7. It needs a mixin (rather than a base) because of the parent skin. Soon, I'll start working on moving Wuthering and Warm to the root. Should be simpler to manage in the end... Child skins really should be there only to change a few lines, not create completely new skins. Just because I could doesn't mean I should have. I need to see a doctor. (Wuthering/extra.css)
! Typo (number_content instead of number_context). (PersonalMessage.php)
* Translation. (ManageMaintenance.french.php, PersonalMessage.french.php)
* Saving a gzipped byte by reordering two lines. Really. I need a doctor. Now. (index.css)
3894
Features / Re: New revs
« on January 18th, 2013, 09:14 AM »
rev 1854
(7 files, 4kb)
* Replaced CSS long URL shortener with a JavaScript one. It has the main advantage of allowing users to copy and paste complete URLs even if they don't show up as complete in the page. Also, it only adds about 60 gzipped bytes to the JS and removes 4 bytes per URL and saves 24 gzipped bytes from the CSS file, which is really nice. Finally, it shouldn't impair any forums, except maybe really slow ones at load time. The alternative solution would be to do this at PHP time, but I'm not sure it's worth the, albeit minor, extra server load, apart from saving the 60 bytes off JS. I'm keeping my options open about implementing it in PHP. (install.sql, script.js, index.css)
* Added $version variables to add_jquery_ui() and weInitJS(), to make it simpler to update the jQuery versions if patches are released for it. Note that currently, I'm still waiting for Google to update their CDN with jQuery 1.9, to which we'll make the jump then. Because jQuery 2.0 will be shorter than 1.5, it'll be beneficial to all non-IE browsers eventually. (Load.php, Subs-Cache.php)
! Half-assed hack to prevent errors from being generated by permission checks before permissions are loaded. Unfortunately, this doesn't fix the error in itself, but at least it doesn't prevent normal use of a forum, and this error won't be logged any more. (Security.php)
! Just because dns_get_record is callable doesn't mean it's not going to return errors. Meh. Another @ fix... I hate those. (Subs.php)
(7 files, 4kb)
* Replaced CSS long URL shortener with a JavaScript one. It has the main advantage of allowing users to copy and paste complete URLs even if they don't show up as complete in the page. Also, it only adds about 60 gzipped bytes to the JS and removes 4 bytes per URL and saves 24 gzipped bytes from the CSS file, which is really nice. Finally, it shouldn't impair any forums, except maybe really slow ones at load time. The alternative solution would be to do this at PHP time, but I'm not sure it's worth the, albeit minor, extra server load, apart from saving the 60 bytes off JS. I'm keeping my options open about implementing it in PHP. (install.sql, script.js, index.css)
* Added $version variables to add_jquery_ui() and weInitJS(), to make it simpler to update the jQuery versions if patches are released for it. Note that currently, I'm still waiting for Google to update their CDN with jQuery 1.9, to which we'll make the jump then. Because jQuery 2.0 will be shorter than 1.5, it'll be beneficial to all non-IE browsers eventually. (Load.php, Subs-Cache.php)
! Half-assed hack to prevent errors from being generated by permission checks before permissions are loaded. Unfortunately, this doesn't fix the error in itself, but at least it doesn't prevent normal use of a forum, and this error won't be logged any more. (Security.php)
! Just because dns_get_record is callable doesn't mean it's not going to return errors. Meh. Another @ fix... I hate those. (Subs.php)
3895
Archived fixes / Re: Reply Error with Chrome
« on January 18th, 2013, 08:18 AM »I'm not saying that it should be retired overnight, I'm just saying that we might want to consider it. It would also potentially allow us to ditch a lot of the complexity of Class-Editor's PHP code, but at the cost of a little more client weight (which, to be fair, should be cached most of the time)
SCEditor, in case it wasn't known, actually exports bbcode rather than natural HTML.
Nope... it wasn't actually displaying anything I'd typed either. And that's a different bug again to what was in the OP.
All in all, I'd probably say SCEditor is sexier than other editors BECAUSE it's smaller than them, but then again, ours is twice smaller... So to me, it's 10 times sexier because I did the optimizations :P
Just give me three reasons to switch to SCEditor, really!
All of the bugs mentioned in this topic were due to my rewrites, and were things that would have easily broken otherwise, and things that only beta testers could find because we don't use Wysiwyg ;)
3896
Features / Re: New revs
« on January 17th, 2013, 11:10 PM »
rev 1851
(8 files +1, 4kb)
- Replaced some JS substring() calls with substr(), which saves bytes everywhere because substr() was already used a lot. (script.js, editor-func.js, player.js, respond.js)
! Chrome was incorrectly setting the JS is_ff flag to true. Rewrote is_ff to basically mean 'has Mozilla flag, but isn't IE or WebKit.' Saves another 6 gzipped bytes, by the way... (script.js)
! Firefox needed an extra fix for Wuthering linktrees. (Wuthering/extra.css)
* Moved Wine's variable overrides to common.css; reason being that if a file such as editor.css wants to use one of those common variables, they'll first take the value from Weaving's common.css file, then fail to see an override anywhere, because the editor (for instance) doesn't have any interaction with the extra.css file. A bit complicated, I admit, but completely logical. (Wine/common.css, Wine/extra.css)
* Translation. (Admin.french.php)
@ Editor fixes coming later, or at least separately... I'm not 100% happy with them right now, and will take some time to review them.
(8 files +1, 4kb)
- Replaced some JS substring() calls with substr(), which saves bytes everywhere because substr() was already used a lot. (script.js, editor-func.js, player.js, respond.js)
! Chrome was incorrectly setting the JS is_ff flag to true. Rewrote is_ff to basically mean 'has Mozilla flag, but isn't IE or WebKit.' Saves another 6 gzipped bytes, by the way... (script.js)
! Firefox needed an extra fix for Wuthering linktrees. (Wuthering/extra.css)
* Moved Wine's variable overrides to common.css; reason being that if a file such as editor.css wants to use one of those common variables, they'll first take the value from Weaving's common.css file, then fail to see an override anywhere, because the editor (for instance) doesn't have any interaction with the extra.css file. A bit complicated, I admit, but completely logical. (Wine/common.css, Wine/extra.css)
* Translation. (Admin.french.php)
@ Editor fixes coming later, or at least separately... I'm not 100% happy with them right now, and will take some time to review them.
3897
Archived fixes / Re: Reply Error with Chrome
« on January 17th, 2013, 10:20 PM »Bloody WYSIWYG editor, it's broken again. The activated arrow icon is a big giveaway.
Methinks it might be time to consider adopting SCEditor like SMF 2.1 has.
1/ the editor's iframe body needs a proper reset. There are too many items that are changed in either html or body tags in the container page... for now, I'll simply stick to fixing the skins one by one. :(
2/ the issue reported here was about the lack of a cursor, right...? This was due to Chrome being detected as both is_chrome and is_ff. I rewrote the is_ff detection code, it's now 6 gzipped bytes shorter (lulz!), and should work properly. Tested before and after the change -- it was indeed that.
Phew :) I'm not ready to retire this wysiwyg crap yet! :p
3898
Features: Forward thinking / Re: jQuery support
« on January 17th, 2013, 09:37 PM »
Both versions will be available in CDN anyway...
1.9 = for IE 6,7,8.
2.0 = for everything else.
They promise that 2.0 final will be even smaller :)
I'm interested in seeing how they're gonna handle the torture of wanting to add a new feature and being forced to do it via a plugin because they're not planning to do further major releases after that one... :^^;:
1.9 = for IE 6,7,8.
2.0 = for everything else.
They promise that 2.0 final will be even smaller :)
I'm interested in seeing how they're gonna handle the torture of wanting to add a new feature and being forced to do it via a plugin because they're not planning to do further major releases after that one... :^^;:
3899
Features: Forward thinking / Re: jQuery support
« on January 17th, 2013, 07:14 PM »
So... It seems that jQuery 1.9 final is out, and 2.0 beta is out too :)
The good news is that v2.0 is around the same size as v1.5.2. When gzipped, it's even actually a bit shorter (by around half a KB). It doesn't support old IEs though, so we'll have to include both versions in our repo, and load v1.9 for IE < 9, which is fine by me. Heck, it's not my bandwidth anyway :P
I'll have to work on finishing the conversion to v2.0, though... I suspect I'll have a lot to do. Especially since v1.6 and v1.7 already changed a lot of things themselves.
The good news is that v2.0 is around the same size as v1.5.2. When gzipped, it's even actually a bit shorter (by around half a KB). It doesn't support old IEs though, so we'll have to include both versions in our repo, and load v1.9 for IE < 9, which is fine by me. Heck, it's not my bandwidth anyway :P
I'll have to work on finishing the conversion to v2.0, though... I suspect I'll have a lot to do. Especially since v1.6 and v1.7 already changed a lot of things themselves.
3900
Features / Re: New revs
« on January 17th, 2013, 09:43 AM »
rev 1850
(2 files, 3kb)
! The mixin regex was using an incorrect back-reference (\3 instead of \1), resulting in mixed selectors only inserting their first property into parent selectors. Oops. This was unfixed until now because I'm only using the 'mixes' keyword for a single selector and it only needed the first property in most situations. (Class-CSS.php)
! The mixin regex also didn't accept blank lines in selector declarations. Considering that the tree parser (which is executed later) does accept them, it makes sense to include support for them. As a reminder, regular selectors that you want to use in 'mixes' keywords should be at the root of the file, i.e. don't indent them with tabs. (Class-CSS.php)
* Slight micro-optimization in a loop. (Class-CSS.php)
* Saved an extra declaration for Firefox 2 and below. I know, it doesn't represent a lot of users, but it's still what allowed me to discover the mixin bug, ah ah. As well as a dysfunctional Wuthering linktree, also in Firefox. (common.css)
(2 files, 3kb)
! The mixin regex was using an incorrect back-reference (\3 instead of \1), resulting in mixed selectors only inserting their first property into parent selectors. Oops. This was unfixed until now because I'm only using the 'mixes' keyword for a single selector and it only needed the first property in most situations. (Class-CSS.php)
! The mixin regex also didn't accept blank lines in selector declarations. Considering that the tree parser (which is executed later) does accept them, it makes sense to include support for them. As a reminder, regular selectors that you want to use in 'mixes' keywords should be at the root of the file, i.e. don't indent them with tabs. (Class-CSS.php)
* Slight micro-optimization in a loop. (Class-CSS.php)
* Saved an extra declaration for Firefox 2 and below. I know, it doesn't represent a lot of users, but it's still what allowed me to discover the mixin bug, ah ah. As well as a dysfunctional Wuthering linktree, also in Firefox. (common.css)