So it’s been a while since I’ve written any (good) HTML. Partly because it’s been so long, and partly because I spend a large portion of my days writing HTML tables at the moment, I thought I would give myself a quick refresh (translation: a quick google) before diving in again. I also remember that there were some “good practice” rules that I never quite established the importance of first time round, so there were a few areas which I wanted to revisit. Specifically these were:
Class vs. ID – when to use which
- Floating elements – and the effect this has on inline and block elements
- Relative positioning
- Browser compatibility
Class vs. ID
Ah floats… I had forgotten how annoying they can be – even before browser compatibility is taken into consideration. I thought I had this down, but one of the first things I have just done when writing HTML from scratch is try to float a div left and then stick an inline list inside it. All sorts of padding was suddenly added by my browser which I did not want at all, so I had to go back to the drawing board. Perhaps the most important thing to remember when floating anything is that you must specify a width on the floated element – or anything can happen.
To me this feels a little bit like a hack and I feel guilty about doing it. This is partly because I think that whatever you are trying to do should always be possible with floats, and mixing the two feels like cheating. However today I had to use relative positioning and could not think of any better way to do it. The scenario: An image (which will change in the future), with a headline laid over the top with a semi-opaque background to the headline (headline will also change to correspond to the image). My solution: split up into three separate elements – one for each part – the image, the headline background (of specific height and color and an opacity of 0.6), and the headline (which can’t be part of it’s background as it needs to be solid). The headline background is then relatively positioned on top of the image, then the headline over the top of that. Then everything that naturally comes below this needs to be shifted up using relative positioning too (as the space required for the initial position of the elements remains. That’s a lot of relative positioning. Is there a better way of doing things? Probably. Have I found it yet? No. Ideas on a postcard please.
Luckily this latest project does not have to be IE6 compatible. Unfortunately I am not happy with the idea of building a web page that will not render properly for some users. It’s the sort of thing that will keep me awake at night. IE6 usage is down to just over six per cent as of August 2010, but it is still the officially supported browser within many British workplaces (apparently including my own). So although it is perhaps not necessary, I feel the need to ensure my HTML renders correctly in IE6 (or almost at least!) And this usually leads to lots of little hacks using the *html cheat. In my defense I do use this as a last resort when I have tried everything else I can think of. The double margin bug is by far the worst culprit – full details found on cssnewbie.com. Anyway I feel a bit like I generally spend too much time browser testing at the end and that this certainly isn’t the best way to do things. Luckily in this instance it seems that most browsers rendered my pages in the same way.
What this has taught me
I did a code review with some senior web developers a while ago and it really opened my eyes to how important it is to do things properly. This is particularly crucial when you’re learning. I tend to make the classic young enthusiast mistake and dive straight in without taking the time to consider the best way to do things. I just want to get things done and see immediate results. In my maturity (or something like that…) I have realised this is not always the best way to learn, and that a balance is needed between jumping in with guns blazing, and taking time to think and re-think things through first.