We like your style

Paul Ockenden Read more October 7, 2009

It’s always nice to receive emails from readers, and it’s especially nice when we hear that something we’ve written has been of help or has had a profound influence. Paul received one such email from reader Nick Lauro:

‘Thanks for your recent articles in PC Pro, where you highlighted the use of CSS in web design. As a wannabe web designer/dabbler since 1999, I struggled for not long enough with raw HTML before being introduced to Dreamweaver. Ever since then, I’ve wondered how so many sites manage to look so great without the use of lots of JavaScript or formatting mark-up within the source. It was only after reading your article, which also turned me onto Style Master, that the light bulb went on.

‘It’s changed my whole view of web-page design and given me real focus. Instead of hitting Dreamweaver and throwing in a load of tables and a few JavaScript tricks generated by Dreamweaver, I’ve now gone right back to school to learn the power of CSS. My use of Dreamweaver was akin to putting a huge pan of plain pasta on the stove and adding every conceivable ingredient I thought might enhance its taste, but without knowing exactly why it might make it taste better. But thanks to your article, I’ve discovered the real use of CSS and I’m a reformed character, learning all the time.’

Getting emails like that makes this job worthwhile. Nick goes on to recommend some tutorials and a book, and then asks a question about CSS-designed pages:

‘I still use Dreamweaver to create updatable templates and also in code view, but my main weapon is Style Master and some of the excellent tutorials by Russ Weakley, which you can find at www.maxdesign.com.au. I also recommend his Sams Teach Yourself CSS in 10 Minutes book for anyone wanting to drop Dreamweaver-driven layouts for CSS.

‘Just one question, do you still use tables for forms? Do you think this is possibly one of the few situations where tables are better for positioning elements than CSS?’

Well, Nick, the answer to your question is ‘it depends’. Although some CSS zealots think tables are the spawn of Satan, they’re usually missing one important point: tables do have a perfectly valid use, which not surprisingly is for displaying tabular data. Consider this example: if you want to display a matrix of monthly sales figures for half-a-dozen products, a table would be the perfect mark-up to use. And, likewise, if you had a form where the user could input those sales figures, a table would work well. However, for a typical website contact form, where you might ask for a name, email address, ‘how did you hear about us’ and so on, tables aren’t necessarily the best mark-up to use.

So what are the alternatives? Well, we’re going to be slightly controversial here and show an example using a definition list. Let’s get the controversy out of the way first. A definition list is a listing of related items, whose two parts are the term and the definition, for example:

Camembert: Smelly French cheese, sometimes runny
Stilton: English cheese, blue

In fact, entries in the list can contain multiple terms and/or definitions:

Grass: The green stuff in your lawn; To snitch on someone; A snitch; Herbal Cannabis

Greenhouse
Glasshouse: A place to grow tomatoes

The disputes arise because some people believe definition lists should only be used for terms and definitions – things like dictionaries and encyclopedia entries – while others hold that they may be used for any list of related data. At first, you might lean toward the former view, as after all those tags are called ‘definition term’ and ‘definition description’. However, if you take a look at the relevant W3C specs (www.w3.org), the authors state: ‘Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words’. That’s a fairly clear and unambiguous permission to use a definition list without sticking strictly to terms and their definitions. If W3C can do it, so can we.
So with the controversy sidelined, let us return to our form. A typical

-based form might look like this:

Your Name
Email Address

To do the same kind of thing with a definition list would look something like this:

Note a few things here. First, the form has an id and the button has a class, so we can style them properly. Second, the form labels employ tags to aid accessibility – if you’re going to the trouble to rebuild the form, you might as well do it properly. Third, notice the

tag, which is used to surround a form control group. It both aids accessibility and helps with styling (by default, it throws a box around the form elements).

Speaking of default looks, just deploying this form as is will result in something bland and nothing like the layout seen with the table. To get it looking nice, you need to apply some CSS styling. Here’s the kind of thing you might do:

form#contactform{

background:#f4dddd;

width: 400px;

}

form#contactform input{

width:200px;

border: 1px #E19A84 solid;

}

form#contactform dt{

float:left;

font-weight:bold;

}

form#contactform dd{

text-align:right;

}

form#contactform dd input.button{

background-color:#EFD7C5;

width:8em;

font-weight:bold;

}

form#contactform fieldset{

padding:10px;

border: 1px #E19A84 solid;

}

That’s just our quick take on making the form look a bit nicer, and we’re sure many of you could do better. For a more complete example of a CSS-styled form, take a look at one of Paul’s clients’ contact forms: www.wdbbrands.co.uk

Incidentally, once you do get up to speed with CSS styling, be sure to submit an example or two of your work to the CSS Zen Garden at http://csszengarden.com. Lots of companies and agencies have taken to contacting the people with the most stunning Zen Garden entries and offering them work.

Access problems

There are times in the life of a web designer/application programmer when, because of either a client’s requests or the setup of the hosting web server, they’re forced to program for a technology that wouldn’t be their first choice. Nothing could induce Mark to use Access on a website – let’s face it, even Microsoft doesn’t recommend you do that. And with web licences for SQL Server Express and MySQL both being free, there’s normally little point in going down the Access route for any website that’s expected to get more hits than a Big Brother runner-up.

So it was with much swallowing of pride, a long string of garlic round the neck and a mop to clear the blood off the floor that Mark embarked on a live website that would have Access behind it. What inspired this change of heart? Well, it was for no other reason than the site needed to go live very soon and the only web server that could be used was a shared one at an ISP rather than one of Mark’s own servers. The reason for this restricted choice of server is far too complex to explain here, but it involved large doses of politics, a fair measure of paranoia and a considerable lack of time to get a new server configured and up and running.
The initial website would only be using the Access database to gather data rather than to feed dynamic pages, so its performance shouldn’t be too much of an issue. So Mark fired up his trusty copy of Dreamweaver MX 2004 (yes, yes, we know there’s now version 8, but Mark still finds MX 2004 more productive and slightly more stable, even if at times Dreamweaver’s ‘stability’ means that using it is rather like riding a unicycle on top of a large medicine ball). However, on this occasion, all was going well and Mark created a connection string to connect to the Access database, as he’s done on numerous previous occasions, but to an SQL server. Just to make sure all was well, a click on the Test Connection button showed that the connection string was working fine.

The database showed up in the Database tab of the application window in Dreamweaver and everything seemed well, until Mark went to expand this object to view its tables and nothing appeared. The database definitely contained some tables, as Mark had put them there. Could it be a permissions problem? Some more tests, which involved reducing the access permissions to dangerously open levels, made no difference. So in situations like this, what does the professional do? He Googles. A search revealed that Mark wasn’t the only person to have this problem, but an answer wasn’t easily forthcoming, and even a search on the normally excellent Experts Exchange (www.experts-exchange.com) didn’t help.

After a day or so, just as Mark was seriously considering hand-coding this part of the website, article 179021 in the Macromedia ColdFusion knowledge base (www.macromedia.com) seemed to point to an answer.

Mark doesn’t use ColdFusion, but as this document seemed to describe the problem, and the fix seemed to be related to some new scripts Dreamweaver uses, it felt like it was worth a try. According to the article, the problem occurs only with a specific setup; namely, when using a local ASP.NET or ASP test server running on XP SP 2. This isn’t quite the setup Mark is using, because while his workstation is running XP SP 2 the test server is a Windows 2003 ASP.NET web server. But still, the fault described was exactly the problem Mark was seeing. It appears the problem stems from the _mmServrScripts Dreamweaver employs to do lots of its clever database stuff.

The procedure to fix this problem is to download the Dreamweaver Extension Fix, then, for each of your sites, within Dreamweaver go to Site | Advanced | Remove Connection Scripts and quit Dreamweaver. Next, run the extension fix you’ve just downloaded and reopen Dreamweaver. Finally, you’ll have to remake the database connection strings. After doing all this, Mark was rewarded with a view of the tables, with their fields, in the application window and was able to continue developing the website, which went live just two days later. Quite why this problem and its subsequent patch aren’t more conspicuously displayed on the Macromedia website, or perhaps made part of a service patch, who knows?

Content, what content?

When building websites for clients, the need for the clients to update and add pages for themselves will often arise. The term for this task is Content Management, and the tools that support it are called Content Management Systems (CMS). In the past, many of us would sit down and write something of the sort ourselves, as after all a simple CMS isn’t rocket science – at its simplest, text gets added to a database, whose records hold the content of the pages, and then the web pages display this content by querying the database. The client’s editing staff are provided with a Java or JavaScript HTML edit box so they can add text enhancements and change the formatting using styles, and everyone is happy.
But things move on, and rather than go to the expense and time of coding their own CMS, many designers are now using off-the-shelf solutions and integrating these into their clients’ websites. Mark recently spent an enjoyable few days researching, downloading and installing various commercial CMS, a lot of which are open source and run on PHP. However, Mark was looking specifically for ASP or .NET solutions to avoid having to alter open-source code and to host PHP. There are dozens of candidates – just take a look at www.aspin.com for ASP versions, and at the extremely good www.opensourcecms.com for almost all of the CMS systems out there.

What soon became obvious was that some of these products offer almost unlimited capabilities, including forums and email list servers being added with just the click of a button. However, what Mark was looking for was something that wouldn’t scare this particular client with an over-complicated interface, and it was this aspect that took some finding in the end. Mark settled on allinta (www.allinta.com): while not free at $79 per website, charging for it does at least mean there’s some incentive for the company to continue development and provide support.

Mark particularly liked allinta’s simple user interface, its simple setup and the ease with which one’s own web page templates could be added to it. Normally, web pages are served from a database, but if you only have Access available for performance reasons you can use allinta to generate static HTML pages to build your site. Should your client need a web form for their users to fill in, let them build one themselves – a few clicks in allinta and it’s done, and the same with calendars and newsletters. The client doesn’t have to bother you with all this stuff, which leaves you to concentrate on the cool functionality for their site that will really set them apart.

If you need something more complex, try doITlive (www.doitlive.com). This is aimed more at the web-savvy user who’s happy with its complex interface. However, its capabilities of building forums and its much more versatile authoring-approval system mean it could be a system for a webmaster to replace their copy of Dreamweaver for maintaining the site once the templates have been built. There are three levels of licence, ranging from the Lite for a single site at €150, through the Pro for multiple sites at €300, right up to the unlimited sites Dev version at a €800.

Before tackling any web development project these days, you should take a look at some of the stuff others have written. And before you commit to using any such product, look at its support forum and do a search for security problems (if there are any, have they been fixed and how quickly?). The search engines are your friend in this task, so use them wisely.