Tag Archives: css

A New, New Look

So TheStable has been given (another) facelift.  Hopefully this one will last more than a few weeks.  Let me explain.

Wordpress 2.7 was due out soon and I thought to myself (about a month ago) wouldn’t it be nice to have a spiffy new theme to coincide with the next version of Wordpress which also received a significant reworking in the theme department.  So I began planning and desigining and theming and coding and produced a cool theme.  In my travels I discovered WooThemes who provided the base for the previous theme (although in the end it was only really a skeleton) and stupidly checked their site recently and discovered a new theme which appealed to me greatly.  The clean lines, simple colours and simple structure meant it was easy to build on whilst still containing features that I liked.

So the old theme has been replaced after only a very short time.  The new theme is a customised version of the typebased WooTheme.  The sidebar on the right is smaller, meaning more room for content (thanks Mel for the suggestion), post author’s gravatar now appear with their name in the left column, popular posts (at the bottom) have been replaced with recent Nici art and the ‘featured posts’ section from the previous theme is now included.  There was something missing without it.

I feel sad that the old theme was so short lived but I do feel that the new theme is better in many ways.  Hopefully you like it too.  As usual, this theme is developed to be completely standards compliant and as such is likely to break in Internet Explorer.  If you are using IE, please upgrade your browser to Firefox, Opera, Chrome or Safari or, if you must, IE8.  The site will work in IE7 but won’t look as nice.  There are more than enough rants about that one around, suffice to say that IE is a waste of space.  If the code is standards compliant and it doesn’t render properly it is the fault of the rendering engine, NOT the developer.  Furthermore, web designers/developers should not have to go out of their way to include browser specific ‘hacks’ to make things work on browsers which refuse to comply with the accepted standards.

User Defined Background

You will notice, with TheStable’s new look, that as a user you can change the background colour to your favourite colour. At the very top of the page, on the right, there is a drop down box which lets you choose which background colour you would like to use with the site.  I had some difficulty working out exactly how to achieve this effect in the simplest way possible so I will document what I have done here.

I have played around with colour changing backgrounds or user selected styles in the past but they all revolved around having each style or scheme in a different style sheet.  The user can then decide which scheme they want and their browser will load that sheet.  This is a popular approach and does the job well but if the only variance in the style is, say, one or two lines, it becomes inefficient.  Why load a 10Kb style sheet when you are literally changing only a few bytes?  This approach is better suited to a complete design change or allow the user a choice of multiple themes, compared with different element styles.

So my answer to this is to have a series of classes which can be changed dynamically by the user.  This displays instantly as the styles have already been loaded by the browser (in my instance there is a small image to load as well).  Of course, there is a default style which is used when no selection has been made.

Firstly, we define the styles:

.bg-purple {
background: #ffffff url(images/bg.png) repeat-x fixed;
}
.bg-blue {
background: #ffffff url(images/bg-blue.png) repeat-x fixed;
}
.bg-red {
background: #ffffff url(images/bg-red.png) repeat-x fixed;
}

You can have as few or as many styles as you like.  You can see that we are only declaring the background here but you can potentially change any style you wish.

Next we assign the body of the document the default (bg-purple) class and we put in our select box with colour choices:

<select onchange=”body.className = value;”>
<option value=”bg-purple”>Purple</option>
<option value=”bg-blue”>Blue</option>
<option value=”bg-red”>Red</option>
</select>

Notice here that the onchange attribute has the javascript ‘body.className = value;’.  This is the most efficient way of changing the class for the body but if, for example, you wanted to change the class of a div you would need to use getElementsByID.  Also note that the value of the options match exactly the class name which will be used.

There is still one drawback - the users will have to choose their background preference each time they load the page.  So, lets get a little more complicated.

By writing a cookie when a selection is made, we can then see if the user has made a selection in the past and then use that selection instead of the default.  So we would have:

<select onchange=”body.className = value;var d = new Date(); d.setDate(+60); document.cookie = ‘bgColor=’ +value+ ‘; expires=’ +d+ ‘; path=/; domain=mydomain.com;’”>

instead of:

<select onchange=”body.className = value;”>

This will write a cookie bgColor with the class name selected as the value.  Make sure that you adjust the domain attribute to your domain and you can change the setDate() function to extend/shorten the expiry date of the cookie.

The last thing we will need to do is to include a function that reads our cookie and uses it’s value instead of the default.  From my research, this is inefficient to do in javascript - whereas in php it takes a lot less code.  It is still possible to do in javascript so if you don’t use php then you aren’t lost.  Please do share if you come up with a solution.

So we use:

<body class=”<?php if (isset($_COOKIE['bgColor'])){echo $_COOKIE['bgColor'];} else { echo “bg-purple”;}?>”>

As you can see it’s a neat bit of code which checks if our cookie exists and uses it if it does or uses the default if it doesn’t.  Now, when the page is refreshed, the users colour choice stays.  The cookie will however expire but if you wished you could rewrite the cookie on each page load, extending the expiry date.  Or you could just be lazy!

Hopefully this helps someone and if you have any ideas, improvements or alterations please do share them.

Web Standards

I’m a big believer in standards based web sites and standards based design and as such have tweaked this website to be completely standards compliant. “But wait!” I hear you say, “hasn’t it always been that way?” Well it was up until the creation of the photo gallery. The photo gallery uses a script called thickbox which allows the pictures, when clicked, to display on a css layer ontop of the page. Normally the page fades out a little to draw focus to the new layer however this uses transparency effects which at this time aren’t standards compliant.

The script also contained hacks and what not to make it operate better visually with IE6. Since IE6 doesn’t like to follow standards they, in my opinion, can miss out on the desired visual effects. As a web designer, catering to the needs of users who insist on using a browser which doesn’t make any attempt to integrate W3C standards just perpetuates the problems. If IE users discover that web pages 1) don’t work and 2) look bad then there is greater motivation to switch to a better featured and standards compliant browser.

If you would like the thickbox css file which is standards compliant, you can get it here. Please note that this will make it look less ‘pretty’.