Web Log Costa Blanca

An end-of-year apology to my readers. I don’t post as often as I mean to. One reason is that my posts are becoming too measured—and too all-inclusive. So here is a quick tip for all my readers who are designing or developing Web sites.

It follows from my previous advice on alt text.

You shouldn’t only use words that make it easy for your visitors with visual problems to see your image in their mind’s eye. You should also use a word or phrase from your keyword list. Search engines often pay close attention to the alt text that goes with images.

That’s it. Happy New Year!

In what I take to be a modern classic in graphic design education, Making and Breaking the Grid (Rockport, 2002), Timothy Samara makes the obvious preliminary point. “Pictures and symbols, fields of text, headlines, tabular data: all these pieces must come together to communicate.”

In my last post, I argued that visual display is an integral part of the communication. The messages a Web page delivers are not all in the words, or the content of the images. It’s a mistake to separate ‘content’ from ‘visual display’, and to insist that handling the first must precede development of the second—just as it would be a mistake to insist that the words of a song must all be written before it’s set to music. (We would never have had Paul McCartney’s ‘Yesterday’ if he hadn’t woken up with the entire tune in his head. Then he wrote the words.)

I promised you a few more examples of what I mean.

Layouts themselves communicate a message. Just as a sonnet in praise of anarchy would be incoherent—or deliberately ironic—so would a Web page for (say) an anarchic rock group which had a clear hierarchy and in which every element occupied an orderly place. To work properly, the page needs clashing colours, headlines at the bottom, tilted images with ragged edges, etc., etc. The display is the content.

Colours have obvious meanings. Porn sites convey a sense of excitement and danger by exploiting red and black. Sites for law firms need to be in more subdued colours, with some blue to suggest calm and stability. Sober colours say, “We are solid and reliable”, just as bright colours say, “We can cheer you up.”

Animations, depending on their form and position and colours, say things like, “We are fizzing with ideas” or “We are sophisticated and up-to-date” or “This site will energise you.”

Enough. You can probably make up many more examples yourself.

As should be clear from my last few posts, I am a big fan of what has come to called “the semantic Web.” Part of this movement is about making it easier for machines (computers, or computer software) to read and process Web pages. The other part is about making it easier for people to read and process Web pages.

Who could argue with either aim?

In my post of the 18th November, however, I mentioned that I had “a few caveats.” Let me explain with reference to some recommendations made by Andy Clarke.

Andy is the author of a really stimulating, detailed and up-to-date book on CSS-based Web design: Transcending CSS, published by New Riders earlier this year. He has a Web site about himself and his studio. There is also a site about the book.

Andy argues for a design work flow that proceeds like this:

1. Gather the content.
2. Mark it up meaningfully, i.e., in the order that makes most sense, and with HTML tags inspired by the content itself, and not by thoughts of visual presentation.
3. Use a style sheet to display the final visual page.

My major quarrel with this is that it makes too sharp a distinction between “content” and “visual display.” I would argue that all the visual details of a Web page convey a message—separately, and in various combinations. One trivial obvious example: it may be good for a property site to look cluttered, and difficult to take in at a glance. The clutter conveys the message, “There’s such a lot of stuff here you may well find the property you’re looking for.” In other words, it is itself (part of) the content.

I’ll give a lot more examples in the second part of this post. But first I’d like to mention my minor quarrel with Andy’s proposed work flow. Given that content includes display, there’s no reason why display shouldn’t come first in time, and the page elements created second, to fit the display. Otherwise, it’s a bit like ruling that the words of a song have to come before the music. I admit that many of the world’s greatest songs have been created this way. But a huge number—of masterpieces, too—have been created the other way round. A compose writes a tune, and then a lyricist supplies words to fit the tune.

I would hate this possibility to be ruled out for Web sites.

My last couple of posts have been about freeing HTML. One aspect of this is making the right sort of use of the attributes id and class.

You can assign an id or class attribute to just about any HTML element. An id attribute assigns a unique identifying name to it; a class attribute assigns it to one or more classes. (As the names suggest.)

There are a couple of things here already worth taking note of.

1. Give an element an id, and it’s supposed to be unique. Only one element on the page can have that ID. Many browsers fail to enforce this rule, but as a designer/developer you should never take advantage of this laxness.
2. An element can be a member of several classes. When assigning it, just list the class names with a space between each.

This gives us a first hint in how we can make best use of these attributes. When designing a site as a collection of Web pages, or developing it (through program code and database data) to produce Web pages, we can use IDs for elements that appear just once—perhaps on every page. And we can analyse our material (‘content’) to decide what classes we need.

This will give us some useful rules of thumb for naming: good names for IDs are: “menu”, “content”, “main”, “search-box”, “navigation”, “breadcrumb”, “shell”, “extras”, “logo”, and so on. If we allow ourselves to think about hierarchies—and not get too anxious that we are on the verge of thinking about visual display—we can add “header”, “footer”, “sidebar”, “maincol”, and so on.

I have said that for class names we should analyse our material: this will give us names like “text”, “date”, “link”, “address”, “event”, “price”, “summary”, “exposition”, and so on and so on.

In other words, we can assign elements an ID based on their function—what role they have on the final page—and assign them to classes based on what they contain—or better still, are.

I know, I know. This really is train spotting or bird spotting stuff. (Why are there so few entries in Google for “HTML anorak”?) But it’s also a kind of confession.

In my last post, I wanted to emphasise that the tags I mentioned were bits of HTML, not bits of English. So I first used the tt tag to isolate them: short for ‘teletype’, this is a tag which displays its contents in a monospace font. A few minutes later, I realised my error. Old habits had swung into action while I was concentrating on something else. The tt tag is as bad as the b tag or the i tag. It’s purely presentational. And the tag I needed was there to be used: the code tag, which is there precisely to identify code.

I thought I’d make a list of similar tags: tags I hardly ever use—and have hardly ever seen used. Here they are: abbr, acronym, address, button, cite, colgroup, optgroup, q, tbody, thead, tfoot.

Lots of these tags look really useful, in principle. If you use one or more of them regularly, please leave me an example!

One of the most exciting developments in Web design in recent years has been the increasingly sharp distinction we have been able to draw between content and presentation. As more and more powerful and efficient (not to say beautiful) Web page designs appear, using nothing but style sheets for presentation, HTML markup can be freed—to return to its true semantic roots.

Of course, all this is passing by designers still muddied down in the twentieth-century, using tables for layout, and font tags for type. Like people who insist on driving four-wheel gas-guzzlers in towns, in spite of everything that we know about global warming, they will no doubt persist in their ways until the waters close over their heads.

I myself have a couple of small caveats about the dogmatic and (I believe) artificial limitations placed by some writers on what is to count as ‘content’, because it must never be forgotten that forms and colours also communicate meaning: by no means all a site’s ‘content’ is words. (I’ll come back to this in a later post.) But the main thrust of the missionary work (like the missionary work of Greens) is all to the good.

It’s good, to give one tiny example, to use an h1 tag just because what you’re inserting at that point in your page is your main page header—and not to worry about how big it’s going to be. The size of every header element can be changed in your style sheet, so that for a particular page design, the text in an h1 tag may be smaller than that in an h2 tag. What matters is that one has the text of a primary header, the other the text of a secondary header. You can think exclusively about meaning and message when creating your HTML markup, and about presentation when writing your CSS rules.

This means that we can now use list tags for all lists (such as navigation menu options), however we want them to appear on the final page. We can revive old tags like address for addresses. And so on.

I’ve actually been quite slow, I have to confess, in freeing myself up. Some of my older sites still muddle content and presentation, especially in the naming of IDs and classes. I’ll come to that in my next post!

A friend of mine is just getting into Web site creation and HTML. He bought a standard best-selling book, now in its 7th edition (or whatever). I picked it up and glanced through it.

I immediately realised why it was really not the best book for him. Because it was a revision of a book that was originally published in the 1990s, it still taught HTML page design the old way, using deprecated element tags like font, attributes like align, and introducing page layout via tables.

It did get on to CSS, about half way through the book, but by then the damage will have been done. Why learn a new way of doing things, when you already have a way that works?

My heartfelt advice to beginning Web designers is to use only those HTML elements that mark up the document, staying clear of any tags that define how the page should look in a browser. For visual styling and layout, use CSS. From the word go.

Oh, and though it’s too late for my friend, don’t buy HTML books in their nth edition. Buy one that was first published in 2006 or 2007!

I have one or two original ideas about alt text, but let’s start with the basics.

Firstly, you have to have it. If you don’t have an alt attribute for every image on your Web page, you won’t be producing valid HTML. It won’t validate. Worse, you will be depriving a large number of your visitors, who may be blind or colour-blind or have other visual difficulties. They will not get value from your page.

Secondly, it should provide the next best thing to the image itself. If an image is of something beautiful, for example, you should try to convey that beauty in words. Don’t say

alt="tree"

Say

alt="A cherry tree loaded with pink blossom, glowing
against a clear blue sky"

Similarly, if the image communicates meaning. Spell out the meaning in words. (And if it’s purely decorative and otherwise redundant, should it be on your page at all?)

Of course, we don’t often find the time to do this properly. We’re in a hurry, and want to get on to the next page on the site. And here I must hold up my own hands. I will spend hours getting a page layout right—but not give a few minutes to thinking of really useful alt text. (I mean to do better. I really do…)

Anyway, a couple of tips.

1. Provide a title tag, too, if you don’t want Internet Explorer to display your alt text as a tool tip. An empty string is often useful here—or a single-word caption.
2. Try beginning and ending your alt text with brackets, so plain text browsers like Lynx make it clear it’s not a continuation of other page text. Using the word “Image: ” straight after the opening bracket is often a good idea. So your actual alt text will be something like “(Image: a cherry tree loaded with pink blossom, glowing against a clear blue sky)”

That kind of thing.

There is so much to be said about images on Web sites, and on Web pages. (Two different issues already.) So I thought I’d start with something absolutely basic.

All graphical Web browsers will resize images for you. (Text browsers ignore them; if there is ‘alt’ text, they either display that or read it aloud. I’ll get on to that in the next post.) They will display images with the width and height you specify inside the image tag, whatever the size of the image sitting on the server—the one you uploaded.

This looks like a really helpful feature. (It seems to be taken advantage of by Microsoft Word, when it creates Web pages from Word documents.) However, you should never use this facility. The browser will upload your big images, perhaps at print-ready resolution straight from your camera, before it resizes them. So your page will take forever to load.

You may not notice this yourself, as the site owner/designer, because your browser will cache the big images on your own hard disc. Your pages will come up as fast as you like. But every visitor to your site, even if they have a fast broadband connection, will wait unnecessarily for the browser to upload the pixel-bloated monsters before cutting them down to Web size. They may well go away before the page has finished loading. (I almost always do.)

What you need to do is decide how big you want your images to be on the Web page, and cut them down to that exact size yourself before you upload them to your site. Any photo-editing or image-editing program will do this for you, and there are plenty of free ones available. Many digital cameras and scanners come with a disc which has such a program on—or you can download one from the Web.

All your visitors will be happier and—since they will stay on your site—so will you.

A last few words about fonts, before I move on to images.

Just yesterday, a new client wrote to me about my first design for their property development site: “The letters of the text are a little thin, could you please make them thicker in general, it will be easier to read I suppose?”

As it happens, her eyes were spot on. I had tried the experiment of calling first for elegant Century Gothic. This is not one of the fonts guaranteed to be on every visitor’s machine—but it’s on enough of them for me to take the chance. (I’m so tired of Verdana/Geneva and Arial/Helvetica.) She evidently had the font on her machine.

My response was of course to switch to nice chunky Verdana—again. But I pondered on the assumptions behind her request. She is a partner in a big Russian property development company operating here in Spain, and they have obviously commissioned many print designers. She clearly thought I had the kind of control over fonts that a print designer takes for granted.

And why don’t I? How come Firefox and the Mozilla project are so stand-offish about embedded fonts? There is even an ‘at-rule’ in CSS (@font-face) which is supposed to allow developers to embed fonts. The Mozilla project scorns it.

Why? To go back to an earlier post of mine, my guess is that they are all principled introverts who think that questions of visual display are beneath their notice.

If only there were a few visually stimulated extroverts on the project…