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

[yellowled]

Regarding the width stuff, did you change anything other than what you specifically mentioned?

I don't think so, but I'm not 100% sure. Gee, I should really get a changelog system.

In IE, a percentage width still produces the same problem as before, so I am not sure this is really "solved".

This should now have a px width in IE since ie.css now has a #wrapper { width: 950px; } ..? Someone please tell me that the divs included in #wrapper will/do inherit this correctly or I'll have to puke.

Also, the experimental template I was working on, while very different from BP in certain respects, does NOT have this problem. I guess I need to figure out why. That template does set a % width on a wrapper div, like BP. Setting BODY width in BP instead of #wrapper eliminates this problem, but I still need to figure out why my experimental template can do it on the wrapper, but BP cannot.

Seems like a good idea to check that out

You must be using a screen width of 1024... right? I'm using a 19" LCD with a width of 1280. BIG difference between 950px and 95%.

Yes, I do. Also, I am aware that 950px is a tad narrow on anything bigger than 1024px, but I don't think we can do much about that. Maybe there's some way to check the browser window width using javascript, but I really think we don't want to do that.

IE actually assigns screen space to the countercode DIV even though the only content of it is a comment - that space disappears if you scroll down to page bottom, then reappears if you scroll up. Another wonderful fluke of IE.

I experienced that, too. I only couldn't find out what triggers this behaviour Hmhmhm ... if we set display: none; for #counter_code, does the counter code still work?

Perhaps it would be best to set the default value of that to false, even if you leave the comment. Also, what is the purpose of the elseif?

The default value for that is set to false As for the empty elseif - I'm actually not sure whether it is needed or mandatory, but I have seen it like this in someone else's code ... but I suppose it is not needed ..?

YL

[Don Chambers]

Gee, I should really get a changelog system.

You want even MORE work to do?!! I would not bother.

This should now have a px width in IE since ie.css now has a #wrapper { width: 950px; } ..? Someone please tell me that the divs included in #wrapper will/do inherit this correctly or I'll have to puke.

Sorry for the confusion - it does. I was experimenting by replacing the fixed pixel width with a percentage and noticed a) a fixed width eliminates the problem, even though I thought it left some minor problem and b) setting to a percentage still produces the problem.

I am aware that 950px is a tad narrow on anything bigger than 1024px, but I don't think we can do much about that.

I never really appreciated unused screeen space until I got a much larger monitor a few months ago. However, I think you can expect larger and larger screen sizes with these monitors coming down in price. Widescreen monitors, especially on laptops, are also becoming more popular.

Maybe there's some way to check the browser window width using javascript, but I really think we don't want to do that.

Agreed - don't do it.

Hmhmhm ... if we set display: none; for #counter_code, does the counter code still work?

It shouldn't, but why would you?

The default value for that is set to false

You're right - just checked config.inc.php. However, the sandbox had the value set to true, but I changed it to false while I was checking this out in the first place.

As for the empty elseif - I'm actually not sure whether it is needed or mandatory, but I have seen it like this in someone else's code ... but I suppose it is not needed ..?

Should not be needed. I use if's all the time without elseifs. I have, like you, seen numerous code fragments using what amounts to an empty elseif. I always thought it was some kind of editing leftover.

[yellowled]

Gee, I should really get a changelog system.

You want even MORE work to do?!! I would not bother.

Well, I have a file ChangeLog now which is a simple text file in which I put what I've changed every time I change something. What I need now is something to remind me to actually put it into that file ...

However, I think you can expect larger and larger screen sizes with these monitors coming down in price.

Yes - but I tend to prefer giving people with a larger resolution smaller width over giving people with a smaller resolution content they have to scroll vertically Besides, it's "only" the IE users who will have to ... wait a minute. Hm. Hmhmhm. I seem to remember that at least the newer IEs didn't have a problem with the percentage width ... so we could maybe add another .css for the earlier IEs which sets the px width for those ... I'll check that out later tonight or tomorrow.

Hmhmhm ... if we set display: none; for #counter_code, does the counter code still work?

It shouldn't, but why would you?

To avoid the funny scroll-up-scroll-down problem. If we don't display (i.e. hide) #counter_code, there should be no space assigned to it, but the javascript should still be in the html code ..?

As for the empty elseif

Should not be needed.

Already removed. I should maybe check if there are empty elseifs in other .tpl files also ...

YL

[Don Chambers]

I think the changelog idea would be more worthwhile if/when there are revisions to a truly "released" BP template, but that is your call since you are the one doing the work!

This issue of percentage vs fixed is obviously very dependent on the graphical content, most often, in the header/banner area. If it is a picture, then the entire template is likely to be a fixed width equal to that picture.

If it is a repetitive "sliced" graphic (ie repeat-x), percentages are my personal preference, because it takes full use of whatever screen rez any particular user happens to have. We already know this curious header thing disappears with fixed widths, and since you have seen this mystery template of mine I keep referring to, you know that I will have a vested interest in finding the source of the header problem with percentage widths.

It also dawns on me that you could continue using max-width for the #wrapper together with a percentage for browsers that support max-width, then simply use a fixed width for ie.css, which will, of course, not have the advantage of the percentage. All this nonsense will be a moot point if IE7 resolved the percentage issue, but I'd bet IE6 is going to be around for a long time as many home users are not going to be motivated, or nudged, to upgrade to IE7.

As far as elseifs, I think I eliminated a few of them on TPLS I edited.... but I did not review any of them specifically looking for this particular issue. There are still a few TPLS in BP I never reviewed.

[yellowled]

It also dawns on me that you could continue using max-width for the #wrapper together with a percentage for browsers that support max-width, then simply use a fixed width for ie.css, which will, of course, not have the advantage of the percentage.

I'll play with that later this morning when I return to Win/xampp - that's the dangerous part of all this: I'm starting to like working under Win again. That's bad

BTW, another idea for that counter code part would be to put it in <head>, but I'm not sure that's a good idea since we don't check what users actually do in that textarea. <head> would be okay for JS, but probably not for anything else.

All this nonsense will be a moot point if IE7 resolved the percentage issue, but I'd bet IE6 is going to be around for a long time as many home users are not going to be motivated, or nudged, to upgrade to IE7.

I haven't looked at my blog stats for a rather long time, but I suppose we can almost safely ignore IE < 6. However, I unfortunately agree that IE 6 is going to be around for a while.

YL

[d_cee]

Hi Guys

Whilst you've both been busy with these little code/browser niggles I've been looking at the coloursets. I've got one almost finished. It's a fixed width graphic colourset so I've had no problems in FF or Safari but I've not tested it in IE yet as I found out yesterday that my 2 year old daughter is an expert at preventing laptops from booting up!! So I'm without windows at the moment.

If one of you could check it out in windows for me before I finish it and do a liquid, non graphic colourset I'd be grateful. Any comments and improvements also welcome. I know there still quite a few things to do to the template but I want to be sure it doesn't completely fall apart in IE6/7 before I finish it - and I'm not going to get my macbook pro back for a few days yet.

You can check it out at http://daviddot.com

Below are some browser stats from one of my client's sites for the last 1000 visitors that should help confirm which browsers we should support. I've used a client's site stats rather than my own as most visitors to my themes site use Firefox!



No.-----Perc. -----Browser Version
592----59.20%----MSIE 6.0
304----30.40%----MSIE 7.0
38------3.80%-----Safari 1.2
32------3.20%-----Firefox 2.0.0
16------1.60%-----Firefox 1.5.0
6--------0.60%-----Mozilla 4.0
3--------0.30%-----Firefox 0.10.
2--------0.20%-----Firefox 1.0.7
2--------0.20%-----MSIE 5.5
2--------0.20%-----Mozilla 5.0
1--------0.10%-----MSIE 5.01
1--------0.10%-----Firefox 1.0.3
1--------0.10%-----Konqueror 3.5

cheers

Dave

[yellowled]

Hi Dave,

I found out yesterday that my 2 year old daughter is an expert at preventing laptops from booting up!

So Zoë's a mac girl, huh?

If one of you could check it out in windows for me before I finish it and do a liquid, non graphic colourset I'd be grateful. Any comments and improvements also welcome.

Neat! I espacially like the fact that it illustrates the template name However, I suggest to switch the bg graphics, i.e. use the lighter one for sidebars and content. I suppose that way it'll be a little more readable ..?

I could check that out in IE, but my win installation doesn't get net connection, so I'd need a zipfile ..? Maybe Don can check this out online.

Below are some browser stats from one of my client's sites for the last 1000 visitors that should help confirm which browsers we should support. I've used a client's site stats rather than my own as most visitors to my themes site use Firefox!

Great, so we can stop paying attention to IE < 6 altogether

I'm compiling something similar for my own blog as we speak, erm, write, but that seems to take some time since awstats is incredibly slow. Plus, it kept me from checking our latest ideas under win ...

YL

[d_cee]

Hi YL
you should try this link for excellent free stats
http://addfreestats.com/ and I'll sort a zip out later -- gotta get on with some work!

cheers

Dave

[Don Chambers]

David - sounds like your 2y.o. daughter did to your laptop what mine did to my Nikon digicam when she was 2!

Here is an IE6 screenshot of your site: http://chicagoloopcruise.com/library/d_cee_bp_1.jpg

To create this screenshot, I pasted a printscreen into photoshop. After I created the file and uploaded it, I was switching back and forth between FF & IE6. It suddenly dawned on me - it wasn't the header that wasn't stretching to fill #content.... #content WAS being stretched... by the SIDEBARS!

I overlayed a FF screenshot on an IE screenshot. Despite your stated margins of 10px, you clearly had a 20px left margin, and a 20 px right margin. I even measured it - sure enough, the header, navbar, and footer were all 970px, as stated by the #wrapper width, but #content was being stretched to 990.

A little googling, and I came back with this: http://www.positioniseverything.net/exp ... argin.html

So: assuming this does not screw up any other browser (or just put it in IE.css), display: inline; on both sidebars should solve the problem. I tested it with my IE developer kit, and it worked just fine!!!

YL - I was hoping this would fix the IE white space to the far right on your blog, but you are not using margins on your sidebards. Anyway, this is probably something that needs to get into BP. It does not resolve the other issue we have been discussing with percentage width's, but maybe it will steer us to a solution for that as well.

Neat! I espacially like the fact that it illustrates the template name

Ummmm... if it is "BulletPROOF", why are their holes in the header? LOL What would be cool would be a graphic that looks like it was shot from behind, indenting the metal, but not penetrating. Then again, maybe Dave was providing a metaphor for the fact that "we ain't done yet"!! LOL!

[d_cee]

Hi guys

I've incorporated your display: inline into the colourset - thanks for checking and working out the fix Don I'd be grateful if you'd check it out again for me as I won't get my laptop back until tomorrow evening. Still not finished yet though.

I've also switched the light/dark 'metallic' graphics YL - see what you think.

Ummmm... if it is "BulletPROOF", why are their holes in the header? LOL What would be cool would be a graphic that looks like it was shot from behind, indenting the metal, but not penetrating.

When I started the colourset I wanted to make it look dented from the back but I took the easy option as I already had the bullet holes from a job I did at work. They're gone for the moment but they'll be back!

Then again, maybe Dave was providing a metaphor for the fact that "we ain't done yet"!! LOL!

If I'd thought of that I'd have done it for sure . I just thought it would be a little amusing in an ironic sort a way.

cheers

Dave

[yellowled]

So: assuming this does not screw up any other browser (or just put it in IE.css), display: inline; on both sidebars should solve the problem.

I have put this in base.css in the latest zip - doesn't seem to screw up anything in FF 2 or Opera 9.

It does not resolve the other issue we have been discussing with percentage width's, but maybe it will steer us to a solution for that as well.

Well, we're back to two extra stylesheets for IE (one for IE 5, one for 6 and 7), so maybe this is already solved

So, here's the ChangeLog for the last 2 days:

Code: Select all

2007-03-28:
	- added width for input and select drop downs in sidebar in
	style.css
	- added display: inline for all sidebars in base.css
	
2007-03-27:
	- removed unnecessary v1.1 cocomment support from commentform.tpl
	- removed link to ie.css from preview_iframe.tpl (should be added
	again once all IE issues are finally solved)
	- copied ie.css (now for IE => 6) to oldies.css (for IE < 6); the
	latter needs a fixed width for #wrapper, ie.css doesn't

So we should have % width in anything but IE 5 now. As far as I have tested it under Win/xampp, it works without flaws.

I also think the fixed width ("optimized for 1024x768 px", urks) will be perfectly fine for those 5 users per month using IE < 6 - if you think about it, those people probably are running Win98 or even 95 on a very old machine. They're not likely to use a huge widescreen LCD with that, right?

Now, about max-width - as far as I know, IE 6 does definitely not support max-width. I'm not 100% sure, but it doesn't seem to work - at least not correctly - in IE 7, either. I just now stumbled over http://www.svendtofte.com/code/max_width_in_ie/, maybe that's a solution - I'll have to check it out first.

Anyway, zipfile and sandbox have been updated. Let's see if this is working fine so far for everyone, then whack IE until it does what we want it to do

YL

[Don Chambers]

Dave - I Like the screws! I use something like that on my boating site. Might I suggest a darker background on BODY... perhaps #666 as a starting point. FYI - your rightsidebar is 193px while your left is 200px. Not sure if that is by design, or not, just pointing it out. The remaining problem I see relates to the footer, but that problem results from display:inline on the sidebars, which I will discuss below.

YL - I know max-width does not work in IE6. I do not have IE7 installed yet. I can assure you that setting width=95% on #wrapper still produces the problem.

The problem has something to do with the sidebar, or at least, that is where I see the symptom, specifically, the rightsidebar. The sidebar does not stay contained within #wrapper the way it should, and ultimately pushes the width of #wrapper too wide, which makes the banner look like it does not completely fill the full width. That is probably not the best description in the world, but that is all I can come up with at the moment.

Back to Dave's. Here is the current state of your site in IE6: http://chicagoloopcruise.com/library/d_cee_bp_2.jpg

The footer inherited a problem from display:inline on the sidebars. It is now too tall. Setting width: 100% fixes the height issue, but like the sidebar problem, pushes the width of #wrapper too wide, which you can see here: http://chicagoloopcruise.com/library/d_cee_bp_3.jpg (note the #666 body background ) . Setting width:100% on the header produces the same problem. Interesting to note that setting width:100% in #SITENAV, while not solving anything, does NOT push the width of #wrapper too wide. A clue perhaps?

Position: relative on the footer partially solves the problem (removes repeating screw graphics), but does not resolve the height issue.

There must be a common denominator here - setting widths to 100% within #wrapper should NOT be causing it to exceed its stated width, yet it does. There is something still lurking out there causing these unexpected width issues. It exists in BP, Dave's current design, and YL's own blog. I have to get some other things accomplished right now, but will try to revisit this issue again today. Maybe you guys will find something before I do.

[yellowled]

YL - I know max-width does not work in IE6. I do not have IE7 installed yet. I can assure you that setting width=95% on #wrapper still produces the problem.

Grmpf. Well, as far as I have googled (haven't tried it yet), max-width is supposed to work in IE7, but doesn't work correctly. I guess I'll simply have to check it out under Win, but I'm beat for today, so that will maybe have to wait a little.

The problem has something to do with the sidebar, or at least, that is where I see the symptom, specifically, the rightsidebar. The sidebar does not stay contained within #wrapper the way it should, and ultimately pushes the width of #wrapper too wide, which makes the banner look like it does not completely fill the full width. That is probably not the best description in the world, but that is all I can come up with at the moment.

I think I know pretty exactly what you mean Let's see - this is something which happens in Dave's test blog, the sandbox and my blog, right? I first thought it was the calendar, but I don't have that in my blog ... I think the only sidebar stuff which is in all of them is the freetag plugin ... I have set "Scale tag font size depending on popularity" to "no" in the sandbox, does that do anything?

The footer inherited a problem from display:inline on the sidebars.

Huh? The footer shouldn't inherit anything from the sidebars IMHO since it's not within the sidebar ..?

I have to get some other things accomplished right now, but will try to revisit this issue again today. Maybe you guys will find something before I do.

Don't bet on me to get anything done before Monday - tough schedule 'til then.

YL

[Don Chambers]

I have set "Scale tag font size depending on popularity" to "no" in the sandbox, does that do anything?

A little - the first tag was preventing the width of the rightsidebar from collapsing any narrower than the full width of the tag name "lorem ipsum". Problem still remains otherwise.

Huh? The footer shouldn't inherit anything from the sidebars IMHO since it's not within the sidebar ..?

Sorry - did not mean inheritence, from a css perspective. Without a display: block on both sidebars, the top of the footer appears to fall BOTTOM of #content.

Don't bet on me to get anything done before Monday - tough schedule 'til then.

Slacker! Actually, I have a ton of other things that require my attention as well. This issue is really ticking me off though.

One final question YL - within index.tpl, you are rendering the leftsidebar first, then content, then rightsidebar. LSB & Content are floated left, RSB is floated right. Did you ever try LSB(float left), then RSB (float right), then Content (float: none)?

[d_cee]

Hi

thanks for the screenshots Don, I'll think I'll take a look tomorrow night when I get my laptop back. I find it easier to resolve these things when I can code on the mac and view on the pc in IE6 and IE7. I'll try and get to the bottom of this width issue too whilst I try and get the colourset to work as it should in IE. And I like the 666 background Don - I've a couple more tiled images to try there before I decide.

One final question YL - within index.tpl, you are rendering the leftsidebar first, then content, then rightsidebar. LSB & Content are floated left, RSB is floated right. Did you ever try LSB(float left), then RSB (float right), then Content (float: none)?

Alternatively what about content first? Always best where possible

cheers

Dave