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.
3901
Features / Re: Improving how smileys are managed
« on January 16th, 2013, 07:43 PM »
Hidden from the post page *and* the smiley popup as well. I usually use hidden smileys to represent elements that are either not interesting to my users (for instance I have both [nobbc]:mdr: and :lol:[/bbcode] smileys, which mean the same in French, so one is 'hidden' because it's only for me -- I don't use it much though), or to add smileys that are too big to fit in the popup, and thus I'd logically rather avoid having them in the CSS file as well.
I don't know, I think it makes sense...
It doesn't prevent you from using the smiley -- it just forces users to an extra HTTP request for them.
Perhaps we could add some UI to ask admins if they want to cache all smileys, or post+popup, or just post smileys...
I don't know, I think it makes sense...
It doesn't prevent you from using the smiley -- it just forces users to an extra HTTP request for them.
Perhaps we could add some UI to ask admins if they want to cache all smileys, or post+popup, or just post smileys...
3902
Features / Re: Improving how smileys are managed
« on January 16th, 2013, 07:11 PM »
Sorry, missed that topic... You should nudge me by PM for any topic you haven't seen me comment on and you need feedback on ;)
I'm not against the idea, I'm against not having a UI for that later... (BBCode :P)
But yep, older versions of IE either don't support data-URIs at all (Wedge redirects IE6 and IE7 to the physical files), while IE8 (or was it IE7? Probably IE7) has support for them, but no more than X bytes, probably 4K I think. Most smileys are under that range. Wedge accounts for this anyway by, IIRC, automatically redirecting to the physical file is the smiley is very large -- because the advantages of having an overall single file for smileys are totally destroyed by having a LARGE file. ;)
So, yeah, it's unlikely that your suggestion would be good in the long run. I can live with knowing that IE6 won't see any smileys at all (what did they do to deserve them anyway? :P), but I can't live knowing that people will have to download a 2MB smiley file because the admin decided to post a lot of animated lulcatz as smileys.
:edit: I'm not sure Wedge also sorts out the smileys that are 'hidden' by default. It would be smart not to include them in the smiley file, I'm guessing, because most likely they won't be used a lot...
I'm not against the idea, I'm against not having a UI for that later... (BBCode :P)
But yep, older versions of IE either don't support data-URIs at all (Wedge redirects IE6 and IE7 to the physical files), while IE8 (or was it IE7? Probably IE7) has support for them, but no more than X bytes, probably 4K I think. Most smileys are under that range. Wedge accounts for this anyway by, IIRC, automatically redirecting to the physical file is the smiley is very large -- because the advantages of having an overall single file for smileys are totally destroyed by having a LARGE file. ;)
So, yeah, it's unlikely that your suggestion would be good in the long run. I can live with knowing that IE6 won't see any smileys at all (what did they do to deserve them anyway? :P), but I can't live knowing that people will have to download a 2MB smiley file because the admin decided to post a lot of animated lulcatz as smileys.
:edit: I'm not sure Wedge also sorts out the smileys that are 'hidden' by default. It would be smart not to include them in the smiley file, I'm guessing, because most likely they won't be used a lot...
3903
Features / Re: Pages: [1] 2 3 styling
« on January 16th, 2013, 02:01 PM »
Event pseudo-classes..?
Okay, unrelated :P
Okay, unrelated :P
3904
Archived fixes / Re: Viewing an unread media item does not mark it as read
« on January 16th, 2013, 01:29 PM »
You have to visit the item page. Maybe. I think Shitiz wrote the logic for this but I remember working on making it work too. Hmm.
3905
Archived fixes / Re: Media buttons broken up
« on January 16th, 2013, 11:34 AM »
It's interesting that yesterday I committed a removal of a fix related to this, although only for Opera and it looked like it didn't need the fix any longer ;)
3906
Features / Re: Pages: [1] 2 3 styling
« on January 16th, 2013, 09:21 AM »
strong tags just suggest emphasis and can always be turned into something else through styling, so I'm opting to keep them, too.
As for brackets, well, yeah, I *guess* we can do without them and add them through pseudo-classes... i.e. strong:before { content: "[" }, strong:after { content: "]" }
As for brackets, well, yeah, I *guess* we can do without them and add them through pseudo-classes... i.e. strong:before { content: "[" }, strong:after { content: "]" }
3907
Features / Re: Pages: [1] 2 3 styling
« on January 16th, 2013, 12:22 AM »
That's wireless only if you ask me.
Then again...
Then again...
3908
Features / Re: Really petty, but I got to ask
« on January 16th, 2013, 12:21 AM »
Like your colored radio button?
Don't see why not! Enjoy yourself.
Don't see why not! Enjoy yourself.
3909
Features / Re: New revs
« on January 15th, 2013, 08:15 PM »
rev 1847
(10 files -2, 7kb)
! Reduced minimum recorded version of Firefox from 16 to 15, to account for the (yet to be upgraded) Pale Moon fork. Hopefully they release v19 soon so I can restore the minimum requirement. (Class-System.php)
! Fixed OS version not being stored in Opera Mini for Android. Actually, they don't even show the Android version in the UA... Not that it's a big deal, as Opera Mini is supposed to look the same across all platforms. (Class-System.php)
! Fixed error log not being able to show source code in context for files outside of the Sources folder. (ManageErrors.php)
! In some rare situations (frankly it's probably down to the filesystem..?), wedge_cache_css_files seems to not be able to create new folders in time for the final recording of the cached file. Just @ignore the error for now... (Subs-Cache.php)
* Moved main CSS IE9 hacks to index.css file. Moved an Opera hack to media.css just the same. Simplified some stuff that seemed to be outdated and no longer needed. (extra.ie9.css, index.css, media.opera.css, media.css)
* Slight improvements to Wuthering header. Moved a single hack for IE6 and IE7 to main file, too. (extra.css, extra.ie6.css, extra.ie7.css)
* Translation. (ManageBans.french.php)
* Spacinazi. (ManageBans.english.php)
(10 files -2, 7kb)
! Reduced minimum recorded version of Firefox from 16 to 15, to account for the (yet to be upgraded) Pale Moon fork. Hopefully they release v19 soon so I can restore the minimum requirement. (Class-System.php)
! Fixed OS version not being stored in Opera Mini for Android. Actually, they don't even show the Android version in the UA... Not that it's a big deal, as Opera Mini is supposed to look the same across all platforms. (Class-System.php)
! Fixed error log not being able to show source code in context for files outside of the Sources folder. (ManageErrors.php)
! In some rare situations (frankly it's probably down to the filesystem..?), wedge_cache_css_files seems to not be able to create new folders in time for the final recording of the cached file. Just @ignore the error for now... (Subs-Cache.php)
* Moved main CSS IE9 hacks to index.css file. Moved an Opera hack to media.css just the same. Simplified some stuff that seemed to be outdated and no longer needed. (extra.ie9.css, index.css, media.opera.css, media.css)
* Slight improvements to Wuthering header. Moved a single hack for IE6 and IE7 to main file, too. (extra.css, extra.ie6.css, extra.ie7.css)
* Translation. (ManageBans.french.php)
* Spacinazi. (ManageBans.english.php)
3911
Archived fixes / Re: parse_bbc_inline does not process colors
« on January 15th, 2013, 05:29 PM »
I worked from a set of very limited elements (b, u, i...) and added tags as I felt I needed them, making sure they were inline type.
I probably should have been more thorough, I think that even though I dislike that tag, it should be in the inline parser anyway...
Could you possibly make a list of tags you feel should be in there..?
I probably should have been more thorough, I think that even though I dislike that tag, it should be in the inline parser anyway...
Could you possibly make a list of tags you feel should be in there..?
3912
Archived fixes / Re: Error in Error log?
« on January 15th, 2013, 05:26 PM »I thought you already had committed it (hadn't checked, head elsewhere)
Currently banging my head over the wall regarding the outline color of the Android icon... White doesn't look good, black is worse, gray lacks detail... And I start editing it to give it white eyes and gray outlines, I'll end up with a file that's over 98 bytes in size, and I don't like it... :^^;:
If it works and doesn't allow people to retrieve any files outside the installation and doesn't allow accessing Settings.php or Settings_bak.php, I'm fine with it.
You might want to double-check its safety aspects, though...
3913
Archived fixes / Re: Error in Error log?
« on January 15th, 2013, 05:01 PM »
Bump before I commit this along with my other changes...
3914
Features / Re: Calendar
« on January 15th, 2013, 07:20 AM »
But it also bypasses the ability to search for posts in these...
3915
The Pub / Re: Looking for volunteers to test the Wedge private alpha!
« on January 14th, 2013, 11:37 PM »
I'm hoping to release a new alpha later this month. We should skip distributing the older alphas ;)
And 5 isn't acceptable :niark:
And 5 isn't acceptable :niark: