Brainstorming: What do we "need" template-wise?

[d_cee]

Hi guys

can you give "serendipity template" a try? I think a lot of people use this app for a long time before they ever understand "s9y", if at all.

I tried this but I couldn't make it fit - even after downloading the smallest pixel font I could find (4px). The only way was to make the button longer and I just didn't think it looked right.

I'm still at work just now but I'll send you the files later when I get home.

Dave

[yellowled]

Sooo, after fighting a little with mod_rewrite, I finally have my dev blog ready, so I can address this little issue:

(Disclaimer: I don't have a test environment under Windows, and I'm not sure I'm going to have one in the near future. So I can't do any IE testing.)

Float the button right, and the credit line left. The footer does not expand to the full height of the button in FF. I recall some issue with the footer, which was fixed with an explicit height (1% - which shoud probably have been 100%), but that does not make any difference either.

True, but this can be solved pretty easily: Just assign a proper height to #footer. The button is 27px high, so 30px would be a sensible value. Of course this is hard to coordinate with the template option to add footer text ...

For FF, float: left on the footer works, but makes the footer only as wide as the left sidebar in IE6. So, a solution would be #footer{float: left} in the colorset stylesheet (if one wanted it that way) and float:none !important in the ie6.css (or earlier ie stylesheets if applicable). I just don't like this solution.

Well, does it work in IE?

Maybe it is an issue of the float needing to be cleared. Maybe you can find a better solution?????

I'll have to do some more reading on this. I kind of like this footer look with the button floated to the right, so we should try to get this solved. However, this should not slow down the release, so if we don't come up with a better solution, I suggest to go with the floated footer.

YL

[Don Chambers]

Actually, I forgot about this since I have been buried in the admin stuff. The behavior is actually quite correct (unfortunately).

The way things currently stand, the footer is not floated. Then we float the image. Specs say that the container (footer) should not automatically expand to contain the floated element (button). IE6 does not (as usual) play by the rules, but in this case, actually does what we would want - expands the footer to contain the floated button.

Specs also say that a container WILL expand to contain a floated element if that container is also floated. At least, that is my understanding of it. Kinda like what we have going on in the navbar... had to float the navbar left so the floated links would force the navbar height to expand to contain them. That particular effort didn't work in IE6 though, hence the need to float:none in ie6.css. So, setting a height will work, and we know the height of the button, but what is not taken into consideration is text size with that solution. So, solution is #footer {float: left} except for ie6.css which is float: none !important; just like the navbar. At least, this solution should be reviewed in various browsers, but I can confirm it is OK in winxp FF and IE6. Also need to then clean up the css files and group all the footer stuff together further down where we have a placeholder for it.

It might also be worthwhile to review each colorset.css file to make sure the rules there are in the same order as style.css, possibly with the same commented titles.

[yellowled]

So, solution is #footer {float: left} except for ie6.css which is float: none !important; just like the navbar. At least, this solution should be reviewed in various browsers, but I can confirm it is OK in winxp FF and IE6.

It should work in anything else, at least I've found that technique in Dan Cederholm's "Bulletproof webdesign" (floating a float).

It might also be worthwhile to review each colorset.css file to make sure the rules there are in the same order as style.css, possibly with the same commented titles.

Yeah, this needs some cleaning up ... as usual, the weekend belongs to my day job, so this will have to wait until Monday.

I've posted a request for lang_*.inc.php translations today, so that's covered. I still need the revamped quicksearch png

YL

[Don Chambers]

Saw your post in "help our developers" section. Hope that attracts some contributions, but cannot help but wonder if we should post that in the general section as well. Lots of folks know absolutely nothing about php, html, css, etc, but could easily translate this. Those people might visit this site, but not necessarily hit that forum folder. Let's give it a week or so if we think it is OK, otherwise, perhaps a duplicate post in the general section.

Anyway, where we stand on the button and stuff? In fact, where we stand on general to-do's? I remember once having an interest in loading the website root as one of the links, I just seem to have gotten bogged down in this admin stuff. Have not even touched my grey stuff in the past week or 2.

I'll shoot you the quicksearch png. Wanted to try a few different settings and test their results in IE first.

[yellowled]

Let's give it a week or so if we think it is OK, otherwise, perhaps a duplicate post in the general section.

Good idea, but I figured since a lot of the translational stuff was being discussed there ...

Anyway, where we stand on the button and stuff?

Button's solved with your IE fix from the last post, I guess. Haven't gotten around to uploading another update yet.

In fact, where we stand on general to-do's?

Well, my ToDo list doesn't contain much any longer. In fact, once I get that quicksearch button and clean the zipfile out a little, there's not much left besides styling the admin backend, and that's a maybe, so it shouldn't keep us from releasing. Hm, and cleaning up the files a little.

I remember once having an interest in loading the website root as one of the links

I either have no idea what you're talking about or don't see what's so difficult about that ..?

YL

[Don Chambers]

Here was what I mentioned once before regarding the home link:

As far as a home link, one of my next tasks was going to be to replace one of the existing navlinks, most likely "music", and make one of them "home". I was going to take that further and try to make the link url equal to $serendipityBaseURL and the link text equal to $CONST.HOMEPAGE..... assuming that worked somewhere between the config.inc.php and language files.

I just have not had a chance to give it a try. Anyway, looks like the button is done, especially since I just re-read that Dave couldn't really work in the "serendipity" text and make it readable.

I have a admin style in purple that could be used, but my intent is to make that a bit more neutral. That is what led to all these other changes I am trying to get to Garvin. I just need to understand a few other little things, and I should be able to wrap that up as well, so I would not rule out an admin style just yet. Guess it really depends on when Garvin will release 1.2, and just how many of my changes he is willing to incorporate.

[yellowled]

Here was what I mentioned once before regarding the home link:

As far as a home link, one of my next tasks was going to be to replace one of the existing navlinks, most likely "music", and make one of them "home". I was going to take that further and try to make the link url equal to $serendipityBaseURL and the link text equal to $CONST.HOMEPAGE..... assuming that worked somewhere between the config.inc.php and language files.

I just have not had a chance to give it a try.

Hm. Why would we want that? Why have a navbar which is completely customizable thanks to Garvin's great code and then insert one element which is not? After all, there is a homelink in s9y (the blog title), so why - in my humble opinion - spoil the customizable navbar with one "fixed" element? What about users who don't want that homelink?

That is what led to all these other changes I am trying to get to Garvin. I just need to understand a few other little things, and I should be able to wrap that up as well, so I would not rule out an admin style just yet. Guess it really depends on when Garvin will release 1.2, and just how many of my changes he is willing to incorporate.

So? Just keep him occupied, maybe you'll be able to slow down that release process long enough because Garvin doesn't have any time to develop because he's answering your questions. Then again, he's got that 36-hours-per-day thing down

YL

[Don Chambers]

I think you misunderstood my intent... the idea was, if possible, to make one of the default links we provide (ie, About, Photos, etc) automagically be a homelink ($serendipityBaseURL) and default to the text of the language file ($CONST.HOMEPAGE). The banner link is not all that obvious, especially when a navbar exists, and not everyone uses those links - we do, afterall, provide the ability to turn off the links and switch to just an image.

I can think of 2, or perhaps 3 ways to accomplish this in the navbar. 1) an admin option, such as "show home page link as first link in the navbar" and 2) an if statement that sets <a href="{$navlink.href}" title="{$navlink.title}">{$navlink.title}</a> to <a href="{$serendipityBaseURL}" title="{$CONST.HOMEPAGE}">{$CONST.HOMEPAGE}</a> if the value of $navlink.href and $navlink.title happens to be a predetermined value (ie "DefaultHome"). The 3rd option, if it exists (and would need Garvin or some other php/smarty expert) would be to find a way to get the actual value of $CONST.HOMEPAGE and $serendipityBaseURL to work in our {foreach from=$navlinks item="navlink"} loop without requiring either of the first 2 options. Make sense?

Anyway, I am sure any of us could knock out the first 2 options in a matter of minutes - I already have a prototype. I would rather check with Garvin on option #3, and will try to do so as soon as I wrap up this admin stuff, if you guys think having such a link available is worthwhile. Again, the idea is to keep it configurable in the admin section and not require an edit of index.tpl to disable it if a user does not want it.

And you are correct - Garvin does have the 36 hour day figured out. In fact, I'd bet he has increased that to nearly 40 by now!!!!

[yellowled]

The 3rd option, if it exists (and would need Garvin or some other php/smarty expert) would be to find a way to get the actual value of $CONST.HOMEPAGE and $serendipityBaseURL to work in our {foreach from=$navlinks item="navlink"} loop without requiring either of the first 2 options.

So, apparently I'm a php/smarty expert

No, I'm not, but I guess I have figured that one out. I'd be much happier if Garvin would check this for any code ... erm ... how do you coder guys call that, overhead? Well, if he just had a look if my code is okay

So here's what I did: I added a new option to config.inc.php to select whether the first navbar item should be a link to the homepage:

Code: Select all

    array(
        'var'           => 'navbar_homelink',
	'name'          => SITENAV_HOMELINK,
        'description'   => SITENAV_HOMELINK_DESC,
        'type'          => 'radio',
        'radio'         => array('value' => array('true', 'false'),
                                 'desc'  => array(BP_YES, BP_NO)),
        'default'       => 'false',
    ),

And I altered the code for our trusty navbar like this:

Code: Select all

   <ul>
     {foreach from=$navlinks item="navlink" name=navbar}
     <li{if $currpage == $navlink.href} class="currentpage"{/if}><a href={if $smarty.foreach.navbar.first && $template_option.navbar_homelink == 'true'}"{$serendipityBaseURL}"{else}"{$navlink.href}"{/if} title={if $smarty.foreach.navbar.first && $template_option.navbar_homelink == 'true'}"{$CONST.HOMEPAGE}"{else}"{$navlink.title}"{/if}>{if $smarty.foreach.navbar.first && $template_option.navbar_homelink == 'true'}{$CONST.HOMEPAGE}{else}{$navlink.title}{/if}</a></li>
     {/foreach}
   </ul>

Works perfectly fine. However, I have no idea whether this code is ideal

YL

[Don Chambers]

Wow! That is a bit more intense than what I had considered. I would have simply done an if on the $template_option.navbar_homelink == 'true', and code a separate <li> line for the home link stuff, then proceeded onto the foreach as it currently exists. Yours is considerably more sophisiticated, but also has the downside of being evaluated for every link item.

Regardless of which method is used, let me state one drawback I was already thinking of. Let's say I want the home link, the beauty of which is it will exactly match the s9y configuration, so the currentpage class gets set appropriately (no missing or extra slashes, etc). However, lets say I do not happen to like the language file default for what that link is named. In English, it is "Homepage". I personally prefer "Home".

This is why I was leaning toward a solution that was simply that our first navbar default link be something like DEFAULT_HOMEPAGE_URL and DEFAULT_HOMEPAGE_LINK (in all languages), and the tpl contain an if based on that value, then insert $serendipityBaseURL and $CONST.HOMEPAGE where appropriate. The values DEFAULT_HOMEPAGE_LINK would appear like any other value in the admin page, but could be changed by the user.

I'm torn - just throwing out thoughts. Why don't you guys think about the pros/cons of each scenario & post back. Meanwhile YL - your solution is impressive!!! Careful - you might be writing new plugins next!!!

[yellowled]

I would have simply done an if on the $template_option.navbar_homelink == 'true', and code a separate <li> line for the home link stuff, then proceeded onto the foreach as it currently exists. Yours is considerably more sophisiticated, but also has the downside of being evaluated for every link item.

See, I didn't even think of that possibility. Interesting, especially since it gives us the possibility to have or not have the homelink as an extra link apart from the navlinks configured by the user ... hmhmhm. I was also thinking about adding a second option to make the last link a login link, which would probably be also possible using your approach.

I also like your other input on this, so I'll play around with this a little tomorrow morning when I'm back at home.

Meanwhile YL - your solution is impressive!!! Careful - you might be writing new plugins next!!!

Muhaha. I may know some Smarty and a little PHP, but I'm lightyears away from actual coding

YL

[Don Chambers]

Maybe we are killing ourselves over something a user can do quite easily on their own. Here is something REALLY ugly but still requires work:

Code: Select all

     <li{if $currpage==$navlink.href} class="currentpage"{/if}><a href="{if $navlink.href=="DEFAULT_HOMELINK_URL"} {$serendipityBaseURL} {elseif $navlink.href=="DEFAULT_LOGIN_URL"} {$serendipityBaseURL}{$CONST.PATH_ADMIN} {else} {$navlink.href}{/if}" title="{if $navlink.title=="DEFAULT_HOMELINK_TEXT"} {$CONST.HOMEPAGE} {elseif $navlink.title=="DEFAULT_LOGIN_TEXT"} {$CONST.SUPERUSER_OPEN_LOGIN} {else} {$navlink.title}{/if}">{if $navlink.title=="DEFAULT_HOMELINK_TEXT"} {$CONST.HOMEPAGE} {elseif $navlink.title=="DEFAULT_LOGIN_TEXT"} {$CONST.SUPERUSER_OPEN_LOGIN} {else} {$navlink.title}{/if}</a></li>

One advantage is that ANY link can be "Home" or "Login". However, here are problems I see. First, the path to the blog MUST end in a "/", or it will not append the admin portion correctly. Second, there are 2 login variables - which of those 2 (SUPERUSER_OPEN_LOGIN and SUPERUSER_OPEN_ADMIN) is used is dependent upon whether the user is logged in or not, so that condition needs to be tested. Excellent examples of checking all this is in /include/plugins_internal.inc.php serendipity_superuser_plugin

Then it dawns on me that we are assigning this stuff in config.inc.php, so perhaps there is some logic that can be applied there, so that our current <li> code does not change, but the value actually assigned for these 2 instances is what we want, not what is in the input box. Plus, I would hate to have some fugly line like I have shown above in all the different navbar locations. Perhaps, if some complicated logic is required, we can take care of it once, then use the results of it (ie, define variables) everywhere else, which is why, once again, I wonder if we can resolve this in config.inc.php.

Anyway, like I first said... maybe this is too far removed from KISS to make it worthwhile. Then again, maybe not.

Meanwhile, I want to get back to admin styling. After a week or so of adding new IDs and classes all over the place (plus a few other neat tweaks), I need to revise my stylesheet to take advantage of a few of them.

[Don Chambers]

Something else I just tripped across.... in trying to match an admin stylesheet to one of our colorsets, I was going crazy wondering why I was having so much trouble with a particular series of font settings. Then I found this in base.css:

Code: Select all

#sitenav, #serendipityLeftSideBar, #serendipityRightSideBar,
#serendipityLeftSideBarLeft, #serendipityLeftSideBarRight,
#content, #footer { font-size: 75%; }

Given the heavy warnings we give about leaving this file alone, which might lead to it not being reviewed at all, I question whether this font setting should exist in base.css. We are setting other font sizes in style.css, so I suggest we move it there. This is admittedly trivial, but it is hardly a "bulletproof" item.

Font sizes in em confuse the hell out of me anyway as they seem to be additive. Should we even bother setting font sizes other than body?

[yellowled]

Anyway, like I first said... maybe this is too far removed from KISS to make it worthwhile. Then again, maybe not.

Yeah, well, we gotta decide one of these days, you know? Here's what I think about it: I think (after a good night's sleep) this whole homelink thingy is one option too many, so I'm removing it.

With Garvin's code for the customizable navbar, users can easily configure any link in that navbar the way they want it to be. That's much better than only months ago when users had to edit the index.tpl to change navbar links. Maybe we're just starting to overthink this whole thing. Time to get ready for release. BTW, where is that friggin' quicksearch png?

Then I found this in base.css:

Code: Select all

#sitenav, #serendipityLeftSideBar, #serendipityRightSideBar,
#serendipityLeftSideBarLeft, #serendipityLeftSideBarRight,
#content, #footer { font-size: 75%; }

Given the heavy warnings we give about leaving this file alone, which might lead to it not being reviewed at all, I question whether this font setting should exist in base.css. We are setting other font sizes in style.css, so I suggest we move it there. This is admittedly trivial, but it is hardly a "bulletproof" item.

Okay, moved to style.css.

Font sizes in em confuse the hell out of me anyway as they seem to be additive.

Huh? What do you mean by "additive"?

Should we even bother setting font sizes other than body?

Yes, because they are "necessary" for the colorsets to work. I remember Dave asking specifically for that 75% setting, so I assume it is important for the colorsets. However, I will test this on the weekend.

YL