An Unfinished Symphony

It's about the internet and stuff.

Where was I?

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.

Up arrow

Style:Phreak's Standard Form Layout Revisited

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.

Up arrow

Safari's margins for error

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
View of ap4a.co.uk in Safari web browser before fixing CSS
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
Margin test using ems - this is a control test
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
Margin test using percentages, not a control test
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
Margin test two, using ems - this is a control test
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
Margin test two, using percentages - this is not a control test
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.

Up arrow