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

[Don Chambers]

Some random thoughts:

style.css, change each of these to this:

Code: Select all

#serendipity_credit_line {
    float: left;
    margin: 5px 0 0 10px;
    display: inline;
}

#serendipity_bulletproof_button {
    float: right;
    margin: 5px 10px 0 0;
    display: inline;
}

Padding doesn't really accomplish what we want it to and the display:inline prevents an IE6 double margin bug.

Index.tpl & iframe_preview.tpl - load the base stylesheet before style.css and the colorsheet. It is, afterall, the one we discourage modifications to, yet in the current order, definitions in base.css override style.css. Need to do the same in commentpopup.tpl *AND* add the colorset line:

Code: Select all

{if $template_option.colorset != 'default'}
<!-- additional colorset stylesheet -->
<link rel="stylesheet" type="text/css" href="{$serendipityHTTPPath}templates/{$template}/
{$template_option.colorset}_style.css" />
{/if}  

Looking at commentpopup for the first time in a LONG time, I can see that our colorsets do not address the background color there, so it inherits the background of body. The id and style in effect for the entire popup are #serendipity_comment_page .s9y_wrap, so we should set one of those to the same background color as entry_body or comment form, or SOMETHING, perhaps even grouping them together so that it is obvious.

Also - click on "comments" for any of your entries. We have a problem, but I do not have time just yet to track it down. Maybe later tonight if one of you do not beat me to it, which I hope you do!!! LOL!

If we do not need text-align: center on body in base.css, then change it to left -or- set text-align: left to .serendipity_Entry_Date in base.css or style.css. This has to do with the entry preview. We still have a slight font descrepancy in preview, but that is because the preview iframe is not constructing all of the containers normally used on the frontend, and a few of the styles in those missing containers are therefore not applying to the preview (unless one of you has time to creatively fix that - and I am not sure it is worthwhile).

I mentioned something to YL about entries.tpl via email, so hopefully he had, or will have, time to quickly fix the entryIcon.

Info.txt.... YL recently added the bp web address. You have s9yDOTbulletproof when it should be DASH.

I'm almost done with all the plugin changes, and will soon get back to the admin styling. While I might show you guys the purple admin I did, I'm thinking I should do something more neutral. Purple is a good choice for BP itself, but probably not if someone wants to use BP as a model for their own and is then stuck with the purple admin or forced to change it, which means even more work for them. Whatcha think?

[yellowled]

Padding doesn't really accomplish what we want it to and the display:inline prevents an IE6 double margin bug.

Done, good call.

Index.tpl & iframe_preview.tpl - load the base stylesheet before style.css and the colorsheet.

Done. Does that in any way affect the preview bug we were talking about via email? I also already moved the IE-related text-aligns for #wrapper to oldies.css.

Need to do the same in commentpopup.tpl *AND* add the colorset line:

Done, I also added the various IE stylesheets here.

The id and style in effect for the entire popup are #serendipity_comment_page .s9y_wrap, so we should set one of those to the same background color as entry_body or comment form, or SOMETHING, perhaps even grouping them together so that it is obvious.

I suggest we simply add .s9y_wrap to the body in each induvidual colorset like this (green as an example):

Code: Select all

body,
.s9y_wrap {
    background-color: #DFD7C3;
}

That should do the trick, right? I don't have the time and patience to test it right now, plus I don't think comment popups are that popular anyway

Also - click on "comments" for any of your entries. We have a problem, but I do not have time just yet to track it down.

Eeeooowww! Now, that's really ugly. I'll see what I can do, but so should you guys. Let's triple-team that one!

If we do not need text-align: center on body in base.css, then change it to left -or- set text-align: left to .serendipity_Entry_Date in base.css or style.css. This has to do with the entry preview.

We do need it in IE<6, which we decided to ignore anyway, to center #wrapper, but I already moved that to oldies.css, so it should be fixed in the next update.

We still have a slight font descrepancy in preview, but that is because the preview iframe is not constructing all of the containers normally used on the frontend, and a few of the styles in those missing containers are therefore not applying to the preview (unless one of you has time to creatively fix that - and I am not sure it is worthwhile).

I'm not sure, either. Let's see if that moved text-align does anything. Apart from that, I think it's not that bad.

I mentioned something to YL about entries.tpl via email, so hopefully he had, or will have, time to quickly fix the entryIcon.

I just sent you an email to discuss this further, but it should be a piece of cake to solve that one.

Info.txt.... YL recently added the bp web address. You have s9yDOTbulletproof when it should be DASH.

You should do skeet shooting or something. You don't miss anything, do you? Corrected.

EDIT:I just now uploaded an updated zipfile including all the last fixes besides that entryIcon thingy. NOTE: Don't be surprised if you experience any difficulties getting that zipfile from my website over the next couple of days. My webspace with all domains is moving to a new server (PHP5/MySQL5) some time tonight, so there might be some downtime.

While I might show you guys the purple admin I did, I'm thinking I should do something more neutral. Purple is a good choice for BP itself, but probably not if someone wants to use BP as a model for their own and is then stuck with the purple admin or forced to change it, which means even more work for them. Whatcha think?

True, a neutral solution would probably be the wiser choice. Try something grey-blueish, that has always worked for s9y admin backends

YL

[yellowled]

Also - click on "comments" for any of your entries. We have a problem, but I do not have time just yet to track it down.

Eeeooowww! Now, that's really ugly. I'll see what I can do, but so should you guys. Let's triple-team that one!

Okay, let's see: It's obviously not an IE issue, since it happens in Firefox as well. It's also not an issue in one of the colorsets since it happens in the 'blank' colorset as well. And it's not a code issue since the html code is generated correctly but displayed wrong.

So the issue must originate either in base.css or style.css. I'm pretty sure it's base.css. If I disable base.css using my trusty webdeveloper toolbar in Firefox, a comment page looks pretty decent. However, if I disable style.css, it's still screwed up.

So the first thing was pretty easy to find: it's the overflow: hidden for #wrapper in base.css which 'hides' everything but the comment form in that view. But there must be something in style.css which in addition is responsible for the page being extra long ... and I guess I have nailed that, too. It's the padding-bottom/margin-bottom combo in style.css which is supposed to produce equal heights columns.

We can probably replace the latter one by using faux columns or something, so that's not really an issue. But I can't remember what exactly we need the overflow: hidden in #wrapper for, do you? I suppose it was an addition by Don (you tend to use overflow a lot more than I do ), but unfortunately my ChangeLog doesn't say why we added it, just when. Any idea before we start to search emails and this thread?

YL

[Don Chambers]

Good job on the cleanups I suggested. Not sure I catch EVERYTHING, but I think this latest series of issues proves we need to thoroughly check everything. Last night, I noticed the overflow:hidden was hiding the top portion of a comment, but that was the point I ran out of energy since I had also just completed my core/plugin revisions. I will get back on it today. If our equal height columns is part of the problem, I am surprised to hear it. Afterall, it is not a problem for entries - only when we jump down to the comment, so there must be some combination there creating the problem.

As far as entries.tpl - I received your email. I think the entryIcon just needs to immediately preceed the entryBody in all instances. It is a simple move in the tpl.

Anyway, let me know if you make any further changes and I will do the same. I just downloaded your latest zip without problems, but if you are having server issues, and change something significant, just email us the modified file(s) until your server issues are resolved.

EDIT: I just emailed you a revised entries.tpl. Works fine in FF and IE6.

[yellowled]

Last night, I noticed the overflow:hidden was hiding the top portion of a comment, but that was the point I ran out of energy since I had also just completed my core/plugin revisions.

Yeah, well, I can relate to that - I just got back from band rehearsal, and I really don't think I can do anything productive tonight

If our equal height columns is part of the problem, I am surprised to hear it. Afterall, it is not a problem for entries - only when we jump down to the comment, so there must be some combination there creating the problem.

That's usually true if something like this happens BTW, I just revisited Alex Robinson's article on the One True Layout, and it says that for this method (the excessive padding/margin values) to work, the container needs overflow: hidden - is that maybe the only reason we need that? Also, Alex mentions issues with that method. Actually, the first issue mentioned is right what we're looking at here:

Linking to an anchor in any of the columns within the element that has been set to overflow: hidden causes the content of that column to shift upwards. In IE and Firefox, that is.

Bottom line: We'll probably "just" have to drop those two things (the overflow for the wrapper and the equal heights stuff) and find another way to get equal heights for the columns. I'd rather not go with faux columns since they require images which have to be edited for every new design. There must be some other way - maybe javascript?

I just downloaded your latest zip without problems, but if you are having server issues, and change something significant, just email us the modified file(s) until your server issues are resolved.

Well, my webspace is schedule to be moved some time tonight, so I assume everything will be back to normal on Monday. And as usual, I won't be able to do much over the weekend anyway, so that's no problem

Got your email, but emailed you some thoughts on the changes.

YL

[yellowled]

Bottom line: We'll probably "just" have to drop those two things (the overflow for the wrapper and the equal heights stuff) and find another way to get equal heights for the columns. I'd rather not go with faux columns since they require images which have to be edited for every new design. There must be some other way - maybe javascript?

Yes, javascript. See http://www.projectseven.com/tutorials/css/pvii_columns/. I've already downloaded the necessary script and will give it a try over the weekend.

Of course, javascript is not ideal, but it seems to be the best solution. We could probably even add another theme option whether to use it or not so users don't have to run unnecessary code in their blog.

YL

[Don Chambers]

While the columns are contributing to the problem, I do not think that is the sole issue. We have had those equal height sidebars for a long time, and this problem did not exist. s9y-bp has not been updated in awhile, and does NOT have this problem!!! Neither does your site, but I do not know how much customization you have done to it.

As far as the quote:

Linking to an anchor in any of the columns within the element that has been set to overflow: hidden causes the content of that column to shift upwards. In IE and Firefox, that is.

I believe we addressed this once before. Not sure how many pages back on this thread I might have to go to find it, but It sounds REAL familiar.

Anyway, I cannot help but wonder if we introduced this bug fairly recently, and it is caused by a combination of the sidebars and something else.

The thing is that the page structure you see when you click on "continue reading" is the same (isn't it?) as when you click on comments... only difference is the page position on #comment. The same methodology happens for continue readin, page is positioned on #extended.

Anyway, I have several old zipfiles. Let me read through some of the recent changes, systematically undo some of them, and see if it produces any results.

[Don Chambers]

Well, I discovered the problem, but in reality, a problem was actually hiding the REAL problem.

Anyway, by looking through some previous versions of BP, I discovered where, on 6/29, some of the stylesheets had been carrying an erroneous "+" (plus) character as the very first character in the stylesheet. This had the result of negating the first style listed in that sheet.

Unfortunately for us, in style.css, that was:

Code: Select all

#serendipityLeftSideBar, #serendipityRightSideBar,
#serendipityLeftSideBarLeft, #serendipityLeftSideBarRight {
    padding-bottom: 20000px;  /* make sidebars equal height */
    margin-bottom: -20000px;  /* make sidebars equal height */
}

So, due to this error, this declaration was never being imposed in our stylesheets until that plus sign was removed. I actually continued using that old style.css (with the plus) for along time in my development copy well after BP was updated to remove it. I even remember saying "hey, we don't have equal height columns anymore" until I finally updated my development copy and said "must have been something *I* did to remove the equal column heights.

So, keeping this method of equal height columns obvious does not work, unless there is a fix out there. I'm not keen on the javascript solution, but if having equal height columns is of greater importance, then we can explore that. I should say, YOU guys can explore it as I know nothing about JS.

I would still like to know why clicking on the "continue reading" link, which is also an anchor element (I think), does not produce the problem, but the comments (and trackbacks) does.

By the way, when this method of equal column heights came up (I was the one that suggested it - check page 19 of this thread), YL's response was:

I'm still not comfortable with that. There are other ways to have equal heights sidebars if someone insists on having them, so I say let's not incorporate this in bulletproof. Might be Pandora's box.

Guess we should have listened then!

[yellowled]

I even remember saying "hey, we don't have equal height columns anymore" until I finally updated my development copy and said "must have been something *I* did to remove the equal column heights.

See, this is what happens if you guys don't keep up with the updates However, in this case it helped a lot since I surely haven't kept copies of all those zipfiles ...

So, keeping this method of equal height columns obvious does not work, unless there is a fix out there. I'm not keen on the javascript solution, but if having equal height columns is of greater importance, then we can explore that. I should say, YOU guys can explore it as I know nothing about JS.

I'll play with the various options we still have later today or tonight, we can probably work it out.

YL

[yellowled]

So, keeping this method of equal height columns obvious does not work, unless there is a fix out there. I'm not keen on the javascript solution, but if having equal height columns is of greater importance, then we can explore that. I should say, YOU guys can explore it as I know nothing about JS.

This is so great: We don't even need the JS. Thumbs up for Dave, who has created three beautiful colorsets which don't need an additional technique for equal heights columns I only removed the excessive padding from style.css, and each colorsets looks and works just fine right now. Oh, and along the way I figured out why we still need the overflow: hidden for #wrapper: it makes the wrapper stretch to the full height of the blog

So users/designers will only need an additional equal heights columns fix if the sidebars are supposed to have a different background color than the entries column. I suggest we point this out in the doc blog and give links to the JS method and the various faux columns techniques (I already have those links, so I'll take care of that entry in the doc blog), and that's it. No need to blow up the bp distribution with code it doesn't actually need.

I would still like to know why clicking on the "continue reading" link, which is also an anchor element (I think), does not produce the problem, but the comments (and trackbacks) does.

So do I, but I suggest we put that aside until after the bp release. Let's get this done first, we're almost there.

I also added a right margin to the navbar links in the blue and green colorsets. If the first link is a home link, it looks better in my humble opinion. Check it out, it's hard to describe (i.e. I'm too lazy to describe it )

So, new updated zipfile. My ToDo list says we still need to check off the following points:

- admin backend styling
- check .tpl files for unnecessary <br />s
- revamped png bp button
- possibly change all font-sizes to % in the colorset stylesheets
- maybe add the purple_body.png Don provided

Don's at the first point, I can do the second, but the latter three are actually Dave's job or call ...

Don't expect much contribution from me over the next couple of days, though. I have to pull some additional nightshifts this (and maybe even next) week, so my schedule is a bit out of sync. I hope I can keep up with you guys.

YL

[Don Chambers]

I assume you are saying we do not NEED equal height sidebars because the 3 colorsets do not set a) a background color different from #content or b) different colors for each sidebar...... correct? If one of those javascript solutions is fairly lightweight, perhaps we should at least give it a try, especially if we can allow the user to turn it on/off in the theme options where a further explanation of "requires javascript" can also be made. I think this would be better than listing a bunch of links where they can find other solutions, most of which would probably require an extensive overhaul of index.tpl.

I checked out your margin change. All I really see is a right margin on the border, so that hover borders to not run into each other and the currently selected link. Is that also correct?

Good thing you did this, as I never check the blue & green colorsets. Turns out using "transparent" on the border has an unusual effect in IE6.... the border inherits the link color!!!! Go figure!!!! In blue, that means all but the selected link has a dark blue appearance. Easy enough fix, just set the border color to the same as #sitenav's background color, so for blue, that is:

#sitenav ul a{
border-bottom: 4px solid #efefef;

and for green:
border-bottom: 4px solid #DFD7C3;



I've been racking my brain for a concept for an admin stylesheet, and one is beginning to form, so hopefully, I will get that rolling. Today is my daughter's 4th b-day, so not much going to happen.

[yellowled]

I assume you are saying we do not NEED equal height sidebars because the 3 colorsets do not set a) a background color different from #content or b) different colors for each sidebar...... correct?

Correct.

If one of those javascript solutions is fairly lightweight, perhaps we should at least give it a try, especially if we can allow the user to turn it on/off in the theme options where a further explanation of "requires javascript" can also be made.

Well, the one I have here is 33 lines of code ... and that's about anything I can say. I'll give it a shot and report back.

I think this would be better than listing a bunch of links where they can find other solutions, most of which would probably require an extensive overhaul of index.tpl.

Nope, they'd only require some additional graphics and some css. But nevermind, we can keep this as a backup.

I checked out your margin change. All I really see is a right margin on the border, so that hover borders to not run into each other and the currently selected link. Is that also correct?

Yup.

Good thing you did this, as I never check the blue & green colorsets. Turns out using "transparent" on the border has an unusual effect in IE6.... the border inherits the link color!!!! Go figure!!!! In blue, that means all but the selected link has a dark blue appearance. Easy enough fix, just set the border color to the same as #sitenav's background color

Will do.

YL

[yellowled]

Okay, so I have added the latest fixes and the javascript option to a new snapshot. I think the javascript slows down rendering the pages a little, but I'm not sure whether it's really significant. I also still have to come up with a good description for that for the lang files.

I also started tracking down redundant <br />s, but that's still in progress.

YL

[yellowled]

I also still have to come up with a good description for that for the lang files.

I also started tracking down redundant <br />s, but that's still in progress.

Both done in yet another new snapshot. I'm a busy bee today. I also added temporary sidebar background colors to style.css in this snapshot so you can easily check if the javascript is working in IE.

YL

[Don Chambers]

I'll checkout the JS shortly. Did nothing yesterday myself, so am trying to get back to the admin template. Cannot decide if I like where it is headed, or want to throw it all out the window and start over. BTW - I wanted to see what some of these links look like in other languages, but I cannot seem to change the language of my development area to anything other than english. Some secret I am not aware of?