Finding your coding voice - and sticking to it
I, like just about every other designer/coder out there, have gone through many phases in the development of the skills I use on a day-to-day basis: HTML, CSS, Javascript, PHP, and a few others on occasion.
From WYSIWYG tools like Dreamweaver (Netscape Composer was actually the program I used to make my first site!), I picked up a few cheap books on HTML and moved on to framesets, nested tables and proprietary Javascript. Next I learned how to work with some of the more complex features of HTML such as forms, and started using rudimentary CSS; and finally I moved to semantic, clean XHTML and a separation of the structure, presentation (CSS) and behaviour (DOM-based Javascript) of the web page.
Obviously this is not a new story, and is probably pretty similar to a lot of other self-taught developers, but what I’d like to talk about is the importance of consistency.
The hobgoblin of little minds
Throughout the course of 2004/5 there have been an incredible number of new approaches or solutions to previous head-scratching problems discovered, with many being published and propagated by design blogs (the many image replacement techniques, including SIFR, are a prime example).
This of course has created a whole new series of problems for web designers – with each new discovery, your entire portfolio is instantly rendered out-of-date and behind the times; do you constantly update your working methods as new approaches are uncovered? Or do you stick with the tried-and-tested approach that you know inside-out?
This dilemma can also apply to existing techniques that you were previously unaware of, as happened to me on a recent project.
Once upon a time…
The site, a bespoke-CMS-driven site for a local company, featured several forms (particularly on the administration panel). Since I discovered accessibility and the <label> element, I have always coded forms like this:
<form>
<fieldset>
<legend>My Form</legend>
<label for="name">Name:</label>
<input type="text" name="name" id="name" />
<label for="age">Age:</label>
<input type="text" name="age" id="age" />
<input type="submit" value="Send" />
</fieldset>
</form>
However I’ve recently adopted a different method of form markup, which I’ve found makes styling much easier:
<form>
<fieldset>
<legend>My Form</legend>
<label for="name">Name:
<input type="text" name="name" id="name" />
</label>
<label for="age">Age:
<input type="text" name="age" id="age" />
</label>
<button type="submit">Send</button>
</fieldset>
</form>
Wrapping the <input> inside the <label> tag, and using a <button> instead of <input type="submit"> has made a big difference to the ease with which I can apply styles to those elements (by, for example, applying “display: block; float: left; clear: left;” to the <label>).
The trouble started when I decided to switch coding methods half-way through the project; predictably, it became twice as much work to go back through all the forms I’d already built and re-code them all. Pretty stupid, right?
But – adopting my new ‘standard’ will (in theory, at least) make it easier for me to make future changes to the site; I won’t have to re-acquaint myself with “the way I used to do things” if I come back to it in a year or more’s time.
What do you do when a new technique presents itself? How many different image replacement methods have you used within the last year?
And has there been anything new that you’ve decided not to use because you’re more comfortable with ‘the old ways’?
Filed under: Design.
Bookmark this article with del.icio.us
Previously: How to stop Textpattern and Textile formatting
Next: Rebooted!
Comments
- Rob Mientjes
- 1303 days ago
- I am not one to answer that, cause I started using web standards just shy of a year ago. FWIW, I did invent some silliness myself, and my best work is completely self-taught.
- #1
