David Anderson's Unfinished Symphony

Dustin Diaz has announced the first annual CSS naked day to take place on the 5th of April. I had wanted to announce my participation in the event prior to my CSS turning off, but I didn't get the chance to and now it's gone.

Some of you may be wondering why I started early - well I haven't really. You see I used the PHP function provided by Luke Wertz to disable my CSS automatically and, as mentioned by Dustin, this will turn the CSS off as soon as it is the 5th of April anywhere in the World, and keep it turned off until it's no longer the 5th anywhere. In other words it's an annual CSS 2 naked days.

To find out what it's all about have a read of the announcement, however it's summed up quite well here by Håkon Wium Lie, the creator of CSS:

This is a fun idea, fully in line with the reasons for creating CSS in the first place. While most designers are attracted by the extra presentational capabilities, saving HTML from becoming a presentational language was probably a more important motivation for most people who participated in the beginning.

Håkon has pledged to take part, along with several hundred other mental people

In a little under 48 hours my CSS will return in a blaze of glory, in the meantime you get to see a more attractive ap4a.

Earlier this week I spent a few minutes tidying up the CSS, removing unnecessary selector duplications, combining identical rule sets, arranging the rule sets more logically, and removing excess white space, and removing whole style sheets that I'd either made obsolete by eliminating the markup they styled, or by including the contents within others that more logically related to their purpose. Basically making the CSS more easy to manage and more logically structured for the way that I work. The reason this was necessary was simply because I was working from someone else's original CSS; CSS that was arranged in a way that they considered logical but to me was haphazard, and only became more haphazard as changes were made, and extra rule sets added. In essence this is only a modified version of the default Kubrick theme for Wordpress.

When I first began to create my own theme for this blog I began by modifying the default which, at the time, seemed like a good idea considering how clean and simple it appeared to be. Looking back it probably wasn't the best idea considering that Kubrick is a very feature rich theme which has a lot of associated template files. What I should have done was either read up on the designing Wordpress themes for public release documentation in order to learn how to do it from scratch, or chosen a simpler theme to develop the basic look from and then added features to that as necessary. That aside I've still managed to learn a fair bit about how the back end of Wordpress works as a result of my tinkering with Kubrick, so it's all good in the long term.

Anyway, as mentioned, a few changes have been made to the CSS. Overall this hasn't had much impact on how the site works in modern browsers, I've tested it and am happy that it looks as intended in Internet Explorer 6 for Windows, Opera 8.52 and Opera 7.23 for Windows, and Firefox 1.5.0.1 for Windows. According to iCapture it also looks right in Safari 2.0.3, so I'm happy with that too. There are a couple of issues on Internet Explorer 5x for Windows however, and possibly IE for Mac - but I have no way of checking that.

In IE 5x for Windows there were, previously, a couple of very minor issues whereby the column side borders didn't quite meet the column headers, being separated by a one or two pixel gap. It was never something that I had bothered to correct as I chose not to use hacks for those browsers to fix a very minor issue in them - considering that they are very old, and very obsolete browsers, and this is a personal site. After the CSS alterations, however, there was slightly more of an issue. In IE 5.5 the third column on the front page dropped down beneath the second column - not something that would cause me any worry by itself, as the site is still fully functional and the drop doesn't detract to much for me to need to fix it for less than 1.5% of the visitors (sorry). In IE 5.01, however, the right-hand column borders were separated by 10 to 20 pixels from the column headers (ie. they were positioned 10 to 20 pixels too far to the right). This was an effect that I'd seen early on in IE 6, and was one that wasn't acceptable. So I've made a couple of minor changes, and even an IE5 stylesheet, to fix the worst of the issues - and after testing in both IE 5.01 and IE 5.5 it seems I've achieved that, with the only outstanding problems being:

1. The Google ads aren't centred. This is easy to fix by using text-align: center; to align them, but I would have to realign anything else that is affected by that and there's a lot that would be affected. All in all it's not enough of an issue to worry about bloating my style sheets in order to fix it.
2. A slight issue with the column headers in IE 5.01 only. If I get the time I may do something to fix that, but it isn't any kind of a priority for me as less than 1% of my visitors use that browser (and those that do could well be me using it for testing, not something that I care to go looking through my raw log files to check on).

Beyond the reorganising of the site's CSS there have been a few other minor changes. A little while ago it was mentioned that the stark black and white colour scheme was a little hard on the eyes, so I softened that with shades of grey. I've also responded to comments by Sarah and Paul, that the site lacked colour, by using colourful versions of new elements that have been added to the site rather than imposing the greyscale colour scheme on them.

I've also overtly linked, using nice colourful icons, to the different versions of the site's feeds to make subscribing easier. I've also included links to various social bookmarking services to the archived version of each post, to make linking individual posts via those services easier on the odd occasion that someone chooses to do so. I will at some stage revise the selection to better target what I consider useful services - which may also include the addition of new services as they become available to the plugin used. I've also expanded the metadata aspects of the site by the inclusion of links to aspects of the Technorati service that apply to this site, as well as the inclusion of a Friend of a Friend profile.

Finally there's also the addition of a couple of features to benefit commentors, such as the inclusion of gravatars on the site to enable them to have a more personalised/branded look to their comments. Also to benefit commentors with their own blogs/sites, I've removed rel="nofollow" from links to their homepage. This is in response to the YesFollow Project that I first read about on Barefoot Boo's blog earlier today. I haven't, however, implemented fully. Firstly, all new comments will have rel="nofollow" in place for the first 3 days in order for me to have time to review the linked site if I feel it necessary, after that initial period it will automagically remove the nofollow from the rel attribute. Second, I have a plugin that adds rel="nofollow" to all links located within the body of comments. I'm leaving this in place as I'd rather not provide endorsements by proxy to third party sites. If I think a site has value to my readership then it's likely to be found in the sidebar links at some point in time - which I'm currently in the process of updating.

So that's pretty much it. Hopefully the changes will prove to be of benefit to some and I'll continue to make changes as I see fit and when time permits, and as the above, hopefully, demonstrates in response to visitor feedback too.

Where was I? It's one of those questions that makes you wonder if you need an alibi, and I've been asked it by Sarah. She wants to know where I was a year ago, 5 years ago and 10 years ago. Bit nosey hey? Ah well, here goes, briefly:

Where was I one year ago?

Working full time as a hotel manager, and part time doing a few freelance web jobs. It was around this time last year, shortly after returning from a 3 month absence following surgery, that I decided I didn't like that job any more and so packed it in and went to work somewhere else for several thousand a year less. Other than that I was spending far too much of my time on web design and internet forums, and drinking beer.

Where was I five years ago?

Happily doing the job mentioned above, along with the (very) odd bit of web work. I was also doing a bit of student tutoring on the side.

Where was I ten years ago?

Spending most of my time being a student at Liverpool University, in the second year of a biochemistry degree, and the rest of the time being a layabout working at a holiday camp in North Wales.

Fascinating stuff, huh?

Apparently I'm supposed to inflict this on 3 other people. I choose Martin Paling, Kev Leitch and Toxie.

In August 2004 Style:Phreak created a demonstration of a standards compliant form marked up with semantic HTML and styled with CSS. I've only recently been introduced to it by an acquaintance from a forum I visit occasionally who uses a version based on it and asked how it could be made more semantic following a brief discussion about it. As a result of that discussion I've taken it upon myself to update it slightly, a possibility brought about due to better support available in current browsers compared to what was available in 2004.

Variations in this version:

• The wrapping of label/input pairs within divs has been dropped as this was only used to allow styling effects to be done to them - those effects are possible without needing to add the extra markup.
• The div surrounding the radio buttons has been replaced with a fieldset, which is more semantic, though it's responsible for the minor issue in Opera 7.23 outlined below.
• Although a tabindex could have been added one hasn't been - as this isn't an active form I decided against this. In a real form one would possibly have been used. Also the erroneous inclusion of one empty tabindex attribute in the original has been omitted here.
• The statement, in the style:phreak original, that fields marked in bold are required is reliant on presentation and would mean that screenreader users won't get the message, this has been replaced with the comment that those marked with a * are required.
• As * marked fields are required it is important that all users get to see it, so it's important that it isn't included via the CSS content property, as per the original.
• As the contents of the "required fields" paragraph contains essential information relating to the form it's more meaningful to include it within the form, so that's done too.
• The script used to toggle the optional fields on and off has been removed in this version, however a script to correct a win IE bug has been included in order to prevent the resetting of select fields when their label is clicked.

This version has been tested and works as intended in the following current Windows browser versions: Internet Explorer 6, Firefox 1.5.0.1 and Opera 8.52. It has also been tested in Opera 7.23 (the lowest version I care about supporting) and found to work with only one error - where the fieldset surrounding the radio buttons is surrounded by a border despite the CSS rule setting it to none. In IE 5.02 and IE 5.5 for Windows it works as intended apart from a misplacement of the textarea and its label, and the wrapping of the label for the input above it on to two lines - I could have corrected this with an IE 5 only stylesheet or a hack, I didn't care enough to try to.

This version, as with Style:Phreak's original is released under a creative commons licence.

View the updated form here.

I was reminded earlier yesterday about a post I've been meaning to write for over a month, when I was given a little feedback on how this site displays in Mac browsers. Whilst the site rendered as expected in Firefox/Mac, there was an issue with the left hand margin on the far left column which consequently was hugging the edge of the browser window in Safari. This came as a bit of a surprise to me, as I'd spotted the issue a month before when using iCapture and thought that I'd fixed all instances of it - seems not. The original problem was far more dramatic than the window hugging left column that I saw today, whereby a couple of the columns had lost their margins and were hugging their neighbour(s)' borders.

A view of this site, and the collapsed margins, in Safari

As you can see, the left hand edge of the first column is hugging the edge of the browser window; whilst the margin set between the left and middle column have collapsed completely, forcing the two columns to align up against each other.

After a review of my CSS I couldn't see any obvious problems - all columns had margins set in percentages, designed to be flexible along with the rest of the layout, and this had proved robust in all the windows browsers which I had tested on including, after a slight modification, in IE. It could only be that it was that slight modification which was the issue. In order to get IE to play nicely I'd had to reduce the margins very slightly, by 0.1% from 1% to 0.9% and it appeared that Safari didn't like non-integer percentage values. In order to check that this was really the case I ran several tests with various sized margins using percentage units alongside controls using ems - ems beings chosen as, like with percentages, decimals are allowed. To view the test page visit Safari Web Browser Margin Tests

Safari Browser - Test One: margins on floated elements

Test One: control example using em-based units

This control test consisted of four equal sized, floated divs being separated horizontally by em-based margins ranging from 0.2em up to 0.8em. As can be seen in the image taken from a screen capture of the Safari Web Browser Margin Tests the margins are working as they should be.

Test One: test example using percentage-based units

This test consisted of four equal sized, floated divs being separated horizontally by percentage-based margins ranging from 0.2% up to 0.8%. As can be seen in the image taken from a screen capture of the Safari Web Browser Margin Tests the margins are collapsing together as described above.

Safari Browser - Test Two: margins on unfloated elements

In order to rule out the possibility that this was a float bug, rather than one related to using non-integer percentage sized margins, it was necessary to conduct a second test on unfloated elements.

Test 2: control example using em-based units

This control test consisted of four equal sized, unfloated divs being separated vertically by em-based margins ranging from 0.2em up to 0.8em. As can be seen in the image taken from a screen capture of the Safari Web Browser Margin Tests the margins are working as they should be.

Test Two: test example using percentage-based units

This test consisted of four equal sized, unfloated divs being separated vertically by percentage-based margins ranging from 0.2% up to 0.8%. As can be seen in the image taken from a screen capture of the Safari Web Browser Margin Tests the margins are still collapsing together.

Safari Margin Tests: Summary

As with any browser, despite it's strong adherence to web standards, Safari has its share of bugs. As a result it can't be ignored during the testing phase of site development, which further emphasises the need to test in all possible browsers on all operating systems available to you. If, like me, you don't have a Mac to test sites you might think testing in Mac only browsers is an impossible task, it isn't. There are a number of services available to help with the task, some free such as iCapture, whilst others are commercial. There's also a number of places to download older versions of the browsers that you might already have on your computer, such as the browser archive at Evolt.org.