Web Log Costa Blanca

One of the easiest things to do in a CSS style sheet is to assign colours to elements. You have just 2 properties to play with, background colour and colour (in style sheets, of course, both properties have to be spelt using American dialect spelling: an Englishman may have invented the Web, but by the time style sheets came along Americans were firmly in control).

I am not here concerned with the more complex colour effects you can get by creating a background image with the effects you want—gradients, radial bursts, stripes, and so on. I just want to make a small point about the use of colour names.

I have 2 recommendations to make, and I make them to the most talented and experienced of my fellow Web designers, because they don’t always follow them.

1. Use the colour names of the 16 originally defined colours: red, green, blue, etc.. It doesn’t take long to learn them. Especially, use black and white. There is absolutely no excuse for writing
   background-color: #000;
color: #fff.
2. Add a comment to any colours that you can only identify using hex (or RGB) values. After
   color: #cf2200,
   add the comment
   /* a red, from garden flower */,
   or at least
   /* a red */

Anyone who has been a programmer as well as a designer knows the value of comments. In particular, they make it easy for other people to identify your colours and your reasons for choosing them, while reading your code. And they make it easier for you, when you come back to the code a few months later.

I should mention here that modern browsers know a huge array of colour names, but I am not suggesting we need to use them, except when by chance a name identifies a shade/hue that we have already chosen. It’s better to get into the habit of adding comments.

Actually, while we’re on the topic of CSS colours, I feel like passing on a practice of my own which is not so generally useful as to count as a recommendation, but which I find really useful as a designer. And here I mean designer, not coder.

I put all my colour rules—for backgrounds and borders as well as text and links— in a separate section at the end of my style sheets. This is a bit of an irritation when coding, since I have to create the other rules for a given element in another section of the style sheet. But it really pays dividends when I want to make small changes to site-wide colour schemes. The relevant values are all together, and can be changed together—sometimes in a single rule.

Why not see if it works for you?

Can you move a Web site based on a proprietary Content Management System to which you have only a customer’s access? The short answer would seem to be ‘no’. One UK Web company includes this question among its FAQs: “Can I move my CMS site to another hosting company?” The answer it gives is “This is not possible as the CMS software that we have developed must remain on our servers.”

There is a general summary of the position on an Australian Web site. This is (part of) what they say about CMS sites:

“Content Management Systems – a mixed blessing
An alternative to a personal web designer is a CMS or Content Management System. The main benefit of a CMS is the ability to update your site yourself – within certain parameters – over the internet, and rolling all your costs into one monthly payment. But you need to go into a CMS contract with your eyes open.
1. CMS do not provide distinctive sites. They are, almost by definition, formulaic. Look at some and see what you think.
2. You don’t own your CMS site in the same way that you own a site designed by a web designer. With CMS you own the content but you cannot walk away from your CMS contract with your site intact – your site can only operate on the CMS operator’s platform.
3. With a CMS website you are locked in – you cannot change to a hosting company that provides more competitive rates or better features without losing your website.”

Point 3 in effect repeats what the English company say about their own sites.

So what was I to do when I was asked to ‘move’ exactly such a Web site, by a potential client to whom I had been recommended—by people I would prefer not to let down?

Of course I said ‘yes’. I committed myself to recreating the site, i.e., constructing a completely new site that would look just like the client’s current site, with a completely new database, a new set of scripts (PHP rather than the current ASP), all the existing images (several hundred of them) and a client interface that let her do everything she had done with the old CMS.

How did I get on in this foolhardy enterprise? Answer in Part 2.

How do people feel about one-page Web sites? For myself, I think they are pretty important, while a real Web site is being developed behind the scenes.

I have a couple of Web sites in this position right now. One is for two karaoke presenters: brookies karaoke. The other is for a friend who wants to sell her unique spacious villa in Calpe. I am doing plenty of work behind the scenes, which the website owners can check out, but neither of the full Web sites are ready yet to go public.

Obviously, you can’t go anywhere further on the site from the home page of a one-page Web site—but at least you can find contact details. What is more, from a website designer’s/owner’s point of view, the minimal Web site is available to be noticed. (And, to my astonishment, Web search engines often find one-page Web sites quite fast.)