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
4291
Features / Re: New revs - Public comments
« on October 19th, 2012, 03:28 PM »
Okay, re: the above...
- I'm not in the mood to rewrite wetem, at least not for now. It's something that can be done much later anyway...
- I'm thinking of adding some skin.xml commands to add/delete a layer or block. Is this a good idea...? Delete is nearly a given, but add is more problematic -- a layer or block would logically be associated with a function... And there's no way to define a custom function in a skin. But I don't see myself adding the 'delete' command without an 'add' somewhere..?!
- Also, I've resumed work on the sidebar thing... The longer I think about it, the stronger my feelings are for simplifying the display:table thing for IE6/7. That is, I'd rather have an unfinished sidebar column for them, than having the sidebar stuck to the side when the window is too small to show it. So, I want to go for divs everywhere.
However, there is still this minor problem: the negative margin hack requires for an intermediate div (or whatever) to be added between <div id="main"> and the main content. What should it be called? Should it be added for all browsers, or just for old IEs? Maybe designers will be glad I added that div if they want to do something special, but OTOH that's already what <div id="main"> was there for... Should it be a special unused tag, like <article>..? Hmm, too bad Ian Hickson said 'no' to a <content> tag... (See article in the latest .Net issue for his rebuttal.)
- Oh, and while I'm at it... The sidebar is the only element in all Wedge that uses the <aside> tag. I don't know if it's worth applying an ID to it..? Why not simply style the <aside> tag? (It's probably faster for the browser to target an ID, but whatever...)
- I'm not in the mood to rewrite wetem, at least not for now. It's something that can be done much later anyway...
- I'm thinking of adding some skin.xml commands to add/delete a layer or block. Is this a good idea...? Delete is nearly a given, but add is more problematic -- a layer or block would logically be associated with a function... And there's no way to define a custom function in a skin. But I don't see myself adding the 'delete' command without an 'add' somewhere..?!
- Also, I've resumed work on the sidebar thing... The longer I think about it, the stronger my feelings are for simplifying the display:table thing for IE6/7. That is, I'd rather have an unfinished sidebar column for them, than having the sidebar stuck to the side when the window is too small to show it. So, I want to go for divs everywhere.
However, there is still this minor problem: the negative margin hack requires for an intermediate div (or whatever) to be added between <div id="main"> and the main content. What should it be called? Should it be added for all browsers, or just for old IEs? Maybe designers will be glad I added that div if they want to do something special, but OTOH that's already what <div id="main"> was there for... Should it be a special unused tag, like <article>..? Hmm, too bad Ian Hickson said 'no' to a <content> tag... (See article in the latest .Net issue for his rebuttal.)
- Oh, and while I'm at it... The sidebar is the only element in all Wedge that uses the <aside> tag. I don't know if it's worth applying an ID to it..? Why not simply style the <aside> tag? (It's probably faster for the browser to target an ID, but whatever...)
4292
Archived fixes / Re: Linktree
« on October 19th, 2012, 03:15 PM »
Oh, it probably compresses better, than it's still not a very exciting implementation to have...
It's basically the same as here:
http://stackoverflow.com/questions/2345132/reversing-z-index-based-from-page-render-order
Not exciting, I told you!
Of course, I could work a bit harder and try to use linear-gradients for the arrow, which would solve all of our problems, but I'm way, way behind CSS gurus when it comes to manipulating gradients... (e.g. Lea Verou)
It's basically the same as here:
http://stackoverflow.com/questions/2345132/reversing-z-index-based-from-page-render-order
Not exciting, I told you!
Posted: October 19th, 2012, 03:14 PM
Of course, I could work a bit harder and try to use linear-gradients for the arrow, which would solve all of our problems, but I'm way, way behind CSS gurus when it comes to manipulating gradients... (e.g. Lea Verou)
4293
Archived fixes / Re: Linktree
« on October 19th, 2012, 02:56 PM »
I'm doing my best, at this point... It's like I'm throwing all of my CSS super-skills into the game.
There's a way to invert the 'arrow' direction, but it involves at least 500 bytes of extra CSS... Meh!
There's a way to invert the 'arrow' direction, but it involves at least 500 bytes of extra CSS... Meh!
4294
Archived fixes / Re: Linktree
« on October 19th, 2012, 02:46 PM »
Bumping this old topic, because it's better than using the thought system for that...
So, this is the best I could come up with. As you can see, it has two drawbacks:
- it's a circle, not an arrow...
- it's pointed to the left, not to the right. It goes against the 'established standards'.
The advantages, though:
- I can set a box-shadow on it.
- I can add hover effects that change the background entirely. (Except for the current entry, because I haven't been able to extend the background width to the entire rest of the line without resorting to HTML...)
What do you think is best..? Current[1], or proposed?
I, myself, have a small preference for the current one. I think I can get around the lack of border by adding another pseudo-element behind it... Hmm, well, I'm not so sure actually, because the current implementation relies on transparent backgrounds a bit too much...
So, this is the best I could come up with. As you can see, it has two drawbacks:
- it's a circle, not an arrow...
- it's pointed to the left, not to the right. It goes against the 'established standards'.
The advantages, though:
- I can set a box-shadow on it.
- I can add hover effects that change the background entirely. (Except for the current entry, because I haven't been able to extend the background width to the entire rest of the line without resorting to HTML...)
What do you think is best..? Current[1], or proposed?
I, myself, have a small preference for the current one. I think I can get around the lack of border by adding another pseudo-element behind it... Hmm, well, I'm not so sure actually, because the current implementation relies on transparent backgrounds a bit too much...
| 1. | See in the Wuthering skin... |
4295
Features / Re: New revs
« on October 18th, 2012, 05:29 PM »
rev 1745 -- woot, plenty of Wess fixes...
(2 files, 5kb)
+ Added is_ios to browser variable. $browser['agent'] will now return 'ios' whether you're on iPod, iPhone or iPad, and whatever browser you're using, because Apple doesn't allow for other browsers to use their own engine. Except for Opera Mini, which should return 'opera', because I like to do things correctly. Also, because I don't have an iPad under the hand, I can't determine whether it's safe to rename extra.iphone.css to extra.ios.css. (Load.php)
+ Added prefix handling support for font-feature-settings and calc() to Wess. (Class-CSS.php)
! Redefining a CSS variable like "$post_bg2 = $window_bg2" could have unexpected results, due to a misplaced call to develop_var(). Well, maybe I'm adding even more bugs by moving it, ah ah. What do you know. Nah, should be good. (Class-CSS.php)
! Undefined variable $is9 in Wess... Not sure how it stayed that way for so long without generating an error... (Class-CSS.php)
! Fixed support for the old flexbox model, and added display: box to the list. Please note that it's recommended to use display: flex or inline-flex instead, these are the new official values, but their support is not as wide. It'll be at least a few years before it starts being useful really... Sob. (Class-CSS.php)
(2 files, 5kb)
+ Added is_ios to browser variable. $browser['agent'] will now return 'ios' whether you're on iPod, iPhone or iPad, and whatever browser you're using, because Apple doesn't allow for other browsers to use their own engine. Except for Opera Mini, which should return 'opera', because I like to do things correctly. Also, because I don't have an iPad under the hand, I can't determine whether it's safe to rename extra.iphone.css to extra.ios.css. (Load.php)
+ Added prefix handling support for font-feature-settings and calc() to Wess. (Class-CSS.php)
! Redefining a CSS variable like "$post_bg2 = $window_bg2" could have unexpected results, due to a misplaced call to develop_var(). Well, maybe I'm adding even more bugs by moving it, ah ah. What do you know. Nah, should be good. (Class-CSS.php)
! Undefined variable $is9 in Wess... Not sure how it stayed that way for so long without generating an error... (Class-CSS.php)
! Fixed support for the old flexbox model, and added display: box to the list. Please note that it's recommended to use display: flex or inline-flex instead, these are the new official values, but their support is not as wide. It'll be at least a few years before it starts being useful really... Sob. (Class-CSS.php)
4296
Features / Re: New revs
« on October 18th, 2012, 05:28 PM »
rev 1744
(5 files, 3kb)
! Mismatched background in stats page. (Stats.template.php)
* Multiple minor CSS tweaks. They're all for the better. Changed windowbg/windowbg2 color in Wine and removed the gradient background (left it on postbg for now). I fear that too many gradients tend to kill the effect. Maybe I'll add them back later. Added a background border between cells in windowbg-alterning tables. Look for the 'final' keyword lost in the middle, it's fun. (common.css, sections.css, Wine/extra.css, Wuthering/extra.css)
(5 files, 3kb)
! Mismatched background in stats page. (Stats.template.php)
* Multiple minor CSS tweaks. They're all for the better. Changed windowbg/windowbg2 color in Wine and removed the gradient background (left it on postbg for now). I fear that too many gradients tend to kill the effect. Maybe I'll add them back later. Added a background border between cells in windowbg-alterning tables. Look for the 'final' keyword lost in the middle, it's fun. (common.css, sections.css, Wine/extra.css, Wuthering/extra.css)
4297
Features / Re: New revs
« on October 18th, 2012, 10:44 AM »
rev 1743
(4 files, 1kb)
* Admin homepage should now show arrows in the newbie box. I have a feeling it should have been done that way since day one... (Admin.template.php)
* I may come to regret this later, but I moved up the body padding reset code for low resolutions. So, instead of being applied to Wuthering, it's now applied to all skins (including Warm, which doesn't need it, but it won't hurt it either.) (sections.css, Wuthering/extra.css)
* Minor tweaks. (Warm/extra.css)
(4 files, 1kb)
* Admin homepage should now show arrows in the newbie box. I have a feeling it should have been done that way since day one... (Admin.template.php)
* I may come to regret this later, but I moved up the body padding reset code for low resolutions. So, instead of being applied to Wuthering, it's now applied to all skins (including Warm, which doesn't need it, but it won't hurt it either.) (sections.css, Wuthering/extra.css)
* Minor tweaks. (Warm/extra.css)
4298
Features / Re: Virtual selectors in WeCSS
« on October 16th, 2012, 12:49 AM »So, I was considering a new feature that I'll add to WeCSS, and need to get some thoughts on it first...
Let's consider this new keyword, 'virtual' (always in line with the C++/Delphi naming scheme.)
.inline-block virtual
display: inline-block
blablabla...
- First idea: July 25, 2012.
- First commit: August 16, 2012.
Now, let's have a look at SASS...
- v3.1.2 adds placeholder selectors, which is very similar to Wedge's virtual selector feature[1] First release: August 10, 2012.
So... It's an impressive coincidence. In the same week, both Wess and SASS added the same feature to their codebase.
But I had the idea first, right...? So I win?
Wrong -- I took a few minutes to go through their github changelog, and found commits related to 'placeholders' that go way before I even got the initial idea. For instance -- https://github.com/nex3/sass/commit/fb917b109b35d505ca659ed83e698896a9b7de91 (that was back in January.)
I must admit I'm a bit disappointed... This was THE latest good idea I had on my own, and it was already done by someone else... :lol:
OTOH, I should be used to that... There are so many people online, I've rarely, if ever, found one of my ideas to really be a first in the forum world. I'm all about innovation, but it's okay if others get the idea before you do. What matters is that you don't get any bad ideas, I guess... :P
| 1. | A quick example... In Wess you'd define ".my_class virtual", while in SASS you'd define "%my_class". It really is pretty much the same, just a matter of syntax preference. I'd even be tempted to add support for 'placeholders' like they did, but really my preference goes to adding a keyword. It's more readable I think. |
4299
Features / Re: New revs
« on October 16th, 2012, 12:24 AM »
rev 1742
(5 files, 2kb)
- We don't need to repeat the schema.org breadcrumb definitions on the bottom linktree in topic pages. Which begs me to ask... Google, why aren't you taking my breadcrumbs into account? Wedge.org has been using then for over 6 months, and yet they're still shown the same way as before... :-/ (index.template.php)
! Minor overflow issue. I'm not sure it's for the best, but it's fixable at any time anyway... (Media.template.php)
* Added a small comment in add_css to remind people that it may fail if calling wetem::hide(). Duh. (Subs-Cache.php)
* Harmonized font size in Wuthering linktree, and linktree padding in Weaving. (index.css, Wuthering/extra.css)
(5 files, 2kb)
- We don't need to repeat the schema.org breadcrumb definitions on the bottom linktree in topic pages. Which begs me to ask... Google, why aren't you taking my breadcrumbs into account? Wedge.org has been using then for over 6 months, and yet they're still shown the same way as before... :-/ (index.template.php)
! Minor overflow issue. I'm not sure it's for the best, but it's fixable at any time anyway... (Media.template.php)
* Added a small comment in add_css to remind people that it may fail if calling wetem::hide(). Duh. (Subs-Cache.php)
* Harmonized font size in Wuthering linktree, and linktree padding in Weaving. (index.css, Wuthering/extra.css)
4300
Features / Re: New revs
« on October 16th, 2012, 12:23 AM »
rev 1741
(2 files, 2kb)
+ Added labels for the permission page, allowing you to click permission names to check/uncheck them. (ManagePermissions.template.php)
* The Clean Cache maintenance task should also empty the CSS and JS cache folders... (ManageMaintenance.php)
(2 files, 2kb)
+ Added labels for the permission page, allowing you to click permission names to check/uncheck them. (ManagePermissions.template.php)
* The Clean Cache maintenance task should also empty the CSS and JS cache folders... (ManageMaintenance.php)
4301
Plugins / Re: Active Members
« on October 15th, 2012, 08:37 PM »
Well, it's still crashing.
But I just realized that it's not the permissions that are a problem at this point, it's the fact that it can't find the 'main' block, which rings no bell to me... I mean, it's the exact same code as in Help.php..?!
(Nope... It's definitely the permissions that trigger the error.)
1/ it's id_member_started, not just id_member...
2/ action=activemembers doesn't have 'topic' but 't' as its topic ID, so no $topicinfo for it... :-/
(Fixed.)
But I just realized that it's not the permissions that are a problem at this point, it's the fact that it can't find the 'main' block, which rings no bell to me... I mean, it's the exact same code as in Help.php..?!
Posted: October 15th, 2012, 08:25 PM
(Nope... It's definitely the permissions that trigger the error.)
Posted: October 15th, 2012, 08:27 PM
1/ it's id_member_started, not just id_member...
2/ action=activemembers doesn't have 'topic' but 't' as its topic ID, so no $topicinfo for it... :-/
Posted: October 15th, 2012, 08:30 PM
(Fixed.)
4302
Plugins / Re: Active Members
« on October 15th, 2012, 08:18 PM »
I'm guessing the line should be something like that...?
Code: [Select]
Hmm, not working... :-/
if (allowedTo('view_active_members_any') || ($topicinfo['id_member'] == $user_info['id'] && allowedTo('view_active_members_own')))Posted: October 15th, 2012, 08:17 PM
Hmm, not working... :-/
4303
Plugins / Re: Active Members
« on October 15th, 2012, 04:48 PM »
Does it work with per-board perms..?
Hmpf... I've enabled the permission for guests and members alike. It still doesn't seem to work...
Have no time to work on this further for now, though.
Oh, and while I'm at it... I guess the #1 thing to do with the plugin is to ensure the word 'more' isn't linkable when the user doesn't have permission to view that popup... Would have saved me some debugging time ;)
Posted: October 15th, 2012, 04:46 PM
Hmpf... I've enabled the permission for guests and members alike. It still doesn't seem to work...
Have no time to work on this further for now, though.
Oh, and while I'm at it... I guess the #1 thing to do with the plugin is to ensure the word 'more' isn't linkable when the user doesn't have permission to view that popup... Would have saved me some debugging time ;)
4304
Plugins / Re: Active Members
« on October 15th, 2012, 04:18 PM »
Hmm, there IS an active_members permission out there.
I didn't notice in the first place.
Maybe the plugin area should indicate whether a plugin is associated with permissions, and give a link to them...? Maybe..?
I didn't notice in the first place.
Maybe the plugin area should indicate whether a plugin is associated with permissions, and give a link to them...? Maybe..?
4305
Plugins / Re: Active Members
« on October 15th, 2012, 04:16 PM »
action=activemembers;t=6998 returns an error 403 for me when I'm logged out, resulting in a popup never showing...
So it's probably down to a wrong permission out there.
:edit: Ninja'd...
So it's probably down to a wrong permission out there.
:edit: Ninja'd...