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
3211
Features / Re: New revs
« on April 14th, 2013, 04:25 PM »
rev 2056 - I just killed XML! Yay!
(7 files -1, 7kb)
! Fixed Split Topics no longer working due to a template change. This has probably been around for a long, long time... (Split.php)
- Removed the last remaining XML templates. Everything is now done through return_xml() calls, and I recommend that you do the same. Again, XML data is not template material. (Ajax.php, Load.php, Post.php, Suggest.php, Xml.template.php)
* More uses of return_raw and return_xml throughout the rest of Wedge. More left to do, but first I need to determine whether I should add more helper functions for return values that don't require being passed through ob_sessrewrite... Minor headache. (Like.php, ManageMedia.php, Split.php)
(7 files -1, 7kb)
! Fixed Split Topics no longer working due to a template change. This has probably been around for a long, long time... (Split.php)
- Removed the last remaining XML templates. Everything is now done through return_xml() calls, and I recommend that you do the same. Again, XML data is not template material. (Ajax.php, Load.php, Post.php, Suggest.php, Xml.template.php)
* More uses of return_raw and return_xml throughout the rest of Wedge. More left to do, but first I need to determine whether I should add more helper functions for return values that don't require being passed through ob_sessrewrite... Minor headache. (Like.php, ManageMedia.php, Split.php)
3212
Features / Re: New revs
« on April 14th, 2013, 12:50 AM »
rev 2055
(1 file +1-1, 84kb)
* Updated jQuery 2.0b1 to beta 3. Odd that they're changing their naming scheme, but whatever... As far as I could see, this beta has no issues, contrary to beta 2, so I hope I won't have to revert it later. It saves an additional 200 gzipped bytes compared to the first beta. Which is particularly nice. (Load.php, jquery-2.0.0-beta3.min.js)
(1 file +1-1, 84kb)
* Updated jQuery 2.0b1 to beta 3. Odd that they're changing their naming scheme, but whatever... As far as I could see, this beta has no issues, contrary to beta 2, so I hope I won't have to revert it later. It saves an additional 200 gzipped bytes compared to the first beta. Which is particularly nice. (Load.php, jquery-2.0.0-beta3.min.js)
3213
Features / Re: New revs
« on April 14th, 2013, 12:43 AM »
rev 2054 -- just some quick ones, too...
(5 files, 3kb)
! Fixed links not being clickable in notifications popup, and added a shortcut to the user's settings page. (Notifications.template.php, Notifications.language.php, script.js)
* Some WebKit browsers, that aren't Chromium-based or Safari itself, don't seem to provide any meaningful version number, so I wrote a short function to match WebKit rev numbers to Safari versions; this is only an estimate, because forks sometimes remove or add features that are not in mainline. But it seems to work well, at least in Lunascape (at least it allows it to use Safari 5.1 features in Wess, instead of Safari 4-level.) (Class-System.php)
(5 files, 3kb)
! Fixed links not being clickable in notifications popup, and added a shortcut to the user's settings page. (Notifications.template.php, Notifications.language.php, script.js)
* Some WebKit browsers, that aren't Chromium-based or Safari itself, don't seem to provide any meaningful version number, so I wrote a short function to match WebKit rev numbers to Safari versions; this is only an estimate, because forks sometimes remove or add features that are not in mainline. But it seems to work well, at least in Lunascape (at least it allows it to use Safari 5.1 features in Wess, instead of Safari 4-level.) (Class-System.php)
3214
Plugins / [Plugin] Re: Notifications system (1.0)
« on April 13th, 2013, 01:58 PM »Yes, I gave it permission. I may be many things but not that naive (I hope :P)
Because I don't see any reason to be paranoid about this? Notifications only show up when you have a tab open with that website in it...
3215
Plugins / [Plugin] Re: Notifications system (1.0)
« on April 13th, 2013, 01:55 PM »
Honestly... To me, it's a given, I will (or someone else will) add support for Chrome notifications in the future... It doesn't seem to be that hard to add, and it solves a lot of problems (including providing a mutex for each notification, allowing for multiple tabs with the same code). I, for one, would be delighted to get these notifications every time someone posts on Wedge or whatever... ;)
3216
Archived fixes / Re: Flexbox bug
« on April 13th, 2013, 01:50 PM »
Two suggestions, to be done with Chrome and dev tools...
- Change .post_wrapper's type from table-row to table
- If it doesn't fix your problem; add a property to .post_wrapper:
table-layout: fixed
I doubt the second one would work, but you'd be surprised the number of things it fixed in my table rewrites, over the years... :lol:
Also, I'm trying to re-consider the flexbox model. I regained some hope after I saw that the latest update to Avant Browser, while still retaining the same Chromium rev number (if I'm not mistaken; at least it's the same major version, i.e. 25), fixes the bug where margins are ignored in posts. Which tends to prove that it was a WebKit bug, not mine... :whistle: Still, bug is still there in Maxthon (Chromium 22), but not Sleipnir (Chromium 25). Which never had it, AFAIK.
So I've simply upped the minimum Chrome version to 26, that way I can be sure that Chromium-based software only implements flex when it's "solid" enough.
I'm still bothered by the fact that Opera is so buggy with flexbox, and yet they don't seem to notice... :-/
Maybe I'll try to submit the bug to them. If it's not too much of a waste of time, considering they're ditching Presto...
PS: just for fun/testing... Flex is disabled on wedge.org right now, but if you add "?flex" to the URL, it'll be re-enabled. (Until you visit a link without that in the URL, of course... °_°)
- Change .post_wrapper's type from table-row to table
- If it doesn't fix your problem; add a property to .post_wrapper:
table-layout: fixed
I doubt the second one would work, but you'd be surprised the number of things it fixed in my table rewrites, over the years... :lol:
Also, I'm trying to re-consider the flexbox model. I regained some hope after I saw that the latest update to Avant Browser, while still retaining the same Chromium rev number (if I'm not mistaken; at least it's the same major version, i.e. 25), fixes the bug where margins are ignored in posts. Which tends to prove that it was a WebKit bug, not mine... :whistle: Still, bug is still there in Maxthon (Chromium 22), but not Sleipnir (Chromium 25). Which never had it, AFAIK.
So I've simply upped the minimum Chrome version to 26, that way I can be sure that Chromium-based software only implements flex when it's "solid" enough.
I'm still bothered by the fact that Opera is so buggy with flexbox, and yet they don't seem to notice... :-/
Maybe I'll try to submit the bug to them. If it's not too much of a waste of time, considering they're ditching Presto...
PS: just for fun/testing... Flex is disabled on wedge.org right now, but if you add "?flex" to the URL, it'll be re-enabled. (Until you visit a link without that in the URL, of course... °_°)
3217
Features / Re: CSS inheritance issue
« on April 13th, 2013, 09:45 AM »
Okay, I had a quick look, and I can't for the life of me remember why I did that background-position thing, especially since it doesn't match the description... :-/ I would logically have added a 'final' keyword to the input.submit re-declaration, and this would have have the effect of doing exactly what you wanted, i.e. no influence over your background-position. Except, the other buttons also need the same background-position...
Honestly, I can't remember either why I did all of this weird stuff in button declarations. I do remember fixing a lot of bugs across multiple browsers, and that there were many precedence problems. I think one of these bugs took me days to fix..
Still. I don't see why you're not declaring this way..?
Code: [Select]
Doesn't compress as well, I reckon, but still, no precedence problem..?
Or simply -- just add the background-position: 5px center line in there as well...
The idea is that 'background' is a shorthand, so if no position is declared, it'll be set to '0 0', so you need to reset it immediately after...
Maybe inheritors should instead declare background-image, not background. Maybe I should do that too, to 'set an example'...
There are plenty of ways to fix this. Ideally, we want the one that compresses better and is the easiest to modify for plugin authors...
Honestly, I can't remember either why I did all of this weird stuff in button declarations. I do remember fixing a lot of bugs across multiple browsers, and that there were many precedence problems. I think one of these bugs took me days to fix..
Still. I don't see why you're not declaring this way..?
input.warn extends input.submit
background: #fff0e3 url($images/warning_ban.gif) 5px center no-repeat
:hover
background-color: #fff5e8Doesn't compress as well, I reckon, but still, no precedence problem..?
Or simply -- just add the background-position: 5px center line in there as well...
The idea is that 'background' is a shorthand, so if no position is declared, it'll be set to '0 0', so you need to reset it immediately after...
Maybe inheritors should instead declare background-image, not background. Maybe I should do that too, to 'set an example'...
There are plenty of ways to fix this. Ideally, we want the one that compresses better and is the easiest to modify for plugin authors...
3218
Features / Re: New revs - Public comments
« on April 12th, 2013, 09:11 PM »
I wanted to rename our new system to 'area=notifications' anyway, so I did that and noticed the other one reappeared, I was the first surprised...
I decided to commit it because at least, it's visible, and we know we have to remove it (or refactor it) at some point...
I decided to commit it because at least, it's visible, and we know we have to remove it (or refactor it) at some point...
3219
Features / Re: Mail entities and stuff.
« on April 12th, 2013, 07:35 PM »
- $message is parsed only once, AFAIK, and then sent to multiple recipients (i.e. sendmail() supports multiple recipients). So I don't think there's any problem with the number of calls to PURL code...
- Then what should we do? Convert anchors to text..?
- Then what should we do? Convert anchors to text..?
3220
Features / Re: New revs
« on April 12th, 2013, 07:32 PM »
rev 2052
(7 files, 6kb)
* Three less XML templates, two to go. (Ajax.php, Register.php, Stats.php, Xml.template.php)
! The old Profile Notifications page is still there, but it wasn't showing up to do duplicate array entries. (Profile.php)
! Typo. (Class-CSS.php)
+ Added tt tag to list of inline BBCodes allowed within parse_bbc_inline. Also, because the parameter list doesn't match parse_bbc's, there's no point in shoving $short_list to the end after some params that are rarely used (such as the cache ID), so I'm moving it to right after the $message param. (Subs-BBC.php)
(7 files, 6kb)
* Three less XML templates, two to go. (Ajax.php, Register.php, Stats.php, Xml.template.php)
! The old Profile Notifications page is still there, but it wasn't showing up to do duplicate array entries. (Profile.php)
! Typo. (Class-CSS.php)
+ Added tt tag to list of inline BBCodes allowed within parse_bbc_inline. Also, because the parameter list doesn't match parse_bbc's, there's no point in shoving $short_list to the end after some params that are rarely used (such as the cache ID), so I'm moving it to right after the $message param. (Subs-BBC.php)
3221
Features / Re: Mail entities and stuff.
« on April 12th, 2013, 12:24 AM »
I applied the ob_ change to Subs-Post here, and tested sending a mail to myself... It works, but there are issues -- for instance, we should add an option to disable shortening of URLs because it ends up stripping the domain name out of the links, oops... I added a temp $context variable, I guess I just need to set it at sendmail time.
There's also another problem with HTML... It shows up as plain code. I'm thinking that there isn't much of a reason NOT to send HTML emails by default... If anything, it kinda defeats the purpose of ob_ to send as plain text, because tags are shown in all their glory... :-/
Or, maybe we should simply fix that and turn anchor tags into text.
There's also another problem with HTML... It shows up as plain code. I'm thinking that there isn't much of a reason NOT to send HTML emails by default... If anything, it kinda defeats the purpose of ob_ to send as plain text, because tags are shown in all their glory... :-/
Or, maybe we should simply fix that and turn anchor tags into text.
3222
Features / Re: CSS inheritance issue
« on April 12th, 2013, 12:15 AM »
Oh...
extra.css then..? It's what this one is there for... ;)
So, extra.member.css is good to ensure it's added after index files, and still restricted to members. Or just extra.css.
This is for a core feature..? Like, in the Wedge SVN? I suppose not, otherwise you'd have added it directly to index.member.css..?
extra.css then..? It's what this one is there for... ;)
So, extra.member.css is good to ensure it's added after index files, and still restricted to members. Or just extra.css.
This is for a core feature..? Like, in the Wedge SVN? I suppose not, otherwise you'd have added it directly to index.member.css..?
3223
Test board / Re: Test topic.
« on April 11th, 2013, 11:54 PM »
Test. @Nao
- Hello, world.
- Nice. Filling this up with a lorem ipsum, or rather I would, but I can't bother to find one. Test..?
3224
Features / Re: CSS inheritance issue
« on April 11th, 2013, 08:01 PM »
i don't get it. I'll have to look into the code in context.
Did you try with a mixes instead..?
I tend to use them a lot these days. Sometimes they compress better ;)
Did you try with a mixes instead..?
I tend to use them a lot these days. Sometimes they compress better ;)
3225
Features / Re: New revs
« on April 11th, 2013, 04:16 PM »
rev 2051 -- minor fixes, anything I could find that could quickly be isolated in a single commit.
(12 files + an attic file, 6kb)
+ Added support for user-select CSS. As Presto will soon be a thing of the past, I really should start changing all of my .mousedown(false) JS calls to proper CSS... Well, it's not that important. (Class-CSS.php)
! Forgot to add avatars to Like notifications. (Class-NotifierLikes.php)
! Also forgot to commit the rest of my chr(15) modifications, part of the JavaScriptEscape magic. (Subs-Cache.php, Subs-Template.php)
* Replaced menurow.gif with an optimized version, which is about twice smaller. This will soon be gone, too, replaced with pure CSS, but if I ever want to restore it, I know where it is now. (images/theme/menurow.gif)
* Renamed .separator class to .sep, which is also unused. It's very trivial, but this morning I needed to save as many bytes as possible, and came up with this... It actually saves 5 or 6 bytes per page load. I wouldn't usually bother, but there were already CSS comments in place that explain what the class stands for, so... Why not shorten its name..? (Unused-SelectBox.js, GenericMenu.template.php, index.template.php, Msg.template.php, extra.ie6.css, extra.ie7.css, sections.css)
- Removing a silly font-size setting that was overriding another override to the default, making no sense at all and wasting over 20 gzipped bytes... This is either me being crazy, or a hickup in team communication. Ship hattens. (sections.css)
(12 files + an attic file, 6kb)
+ Added support for user-select CSS. As Presto will soon be a thing of the past, I really should start changing all of my .mousedown(false) JS calls to proper CSS... Well, it's not that important. (Class-CSS.php)
! Forgot to add avatars to Like notifications. (Class-NotifierLikes.php)
! Also forgot to commit the rest of my chr(15) modifications, part of the JavaScriptEscape magic. (Subs-Cache.php, Subs-Template.php)
* Replaced menurow.gif with an optimized version, which is about twice smaller. This will soon be gone, too, replaced with pure CSS, but if I ever want to restore it, I know where it is now. (images/theme/menurow.gif)
* Renamed .separator class to .sep, which is also unused. It's very trivial, but this morning I needed to save as many bytes as possible, and came up with this... It actually saves 5 or 6 bytes per page load. I wouldn't usually bother, but there were already CSS comments in place that explain what the class stands for, so... Why not shorten its name..? (Unused-SelectBox.js, GenericMenu.template.php, index.template.php, Msg.template.php, extra.ie6.css, extra.ie7.css, sections.css)
- Removing a silly font-size setting that was overriding another override to the default, making no sense at all and wasting over 20 gzipped bytes... This is either me being crazy, or a hickup in team communication. Ship hattens. (sections.css)