Ten Questions for Andy Budd | May 17, 2004

Russ interviewed me for the WSG site a while ago, and I'm please to say he's just published the result.

Enjoy.

Comments (7)

Sony P8 and MPK-PHA Underwater Housing | May 14, 2004

underwater housing

I'm going on a diving holiday to the Red Sea next week and have been thinking about getting a Sony P8 digital camera and an underwater housing. Just wondering if anybody has used the Sony P8 and if it's any good?

Comments (6)

Huge Text Inside Tables on IE5/5.5 | May 14, 2004

It's been known for quite a while that IE5/5.5 ignores text sizes applied to the body tag, inside tables. Doing a search on this issue comes up with a few solutions, mosty involving the use of IE5/5.5 specific hacks. However there is a much, much easier solution. Simply set the font-size for tables to 1em.

body {
	font: 76%/1.6em Verdana, Arial, Helvetica, sans-serif;
}

table {
	font: 1em Verdana, Arial, Helvetica, sans-serif;
}

It's neither clever or sexy, but may be of use to somebody.

Comments (9)

An Objective Look at Table Based vs. CSS Based Design | May 12, 2004

Over the years there have been many great articles extolling the virtues of CSS based design and bemoaning table based design. However there have been very few articles looking at things from the other side of the fence. This is probably because you really have to understand and use CSS based design before you can criticise it. Yet once converted, few (if any) people go back to the old way of coding.

In order to bring some balance back to the equation, and to have a bit of fun playing devils advocate, I’ve decided to write an article about why in some instances, traditional table based design can be as good, if not better than CSS and standards based design.

The Demonisation of Tables

Before tables came along, the web was a pretty dull place. Using tables for layout opened up the possibility of visually “designing” a page. It could be argued that table based layout was responsible for the popularity of the web and the field of web design. That’s right. Without tables, all us web designers would probably be without a job.

Yet over the last few years, table based layout has become demonised. Web purists will tell you that tables were never meant for layout so you shouldn’t use them for such. However history has shown us many examples of technologies that started out life with one purpose, only to ended up finding more practical applications as something else. The web itself was never intended to be anything other than a way of sharing research data, and yet it’s become a channel for entertainment and marketing as well as information and education.

The Comfort Factor

As web designers, we’ve been laying out pages using tables for years. It’s a skill most web designers have, and most are comfortable with. Using tables in this way leads to very predictable results. By using a few very simple hacks, such as spacer gifs, we can pretty much guarantee that our sites will look the same on the widest range of web browsers out there, from the lowliest version of Netscape 4 to modern browsers such as Safari.

Despite the fact that pioneers have been talking about web standards for a long time, the majority of web sites are still developed using tables and non standards compliant code. Because of this, user agents will be forced to handle table based layouts for many years to come. This effectively negates one of the biggest selling points for web standards. That of forward compatibility. It’s highly unlikely that in the near future, any of the big browser manufacturers (um, that’ll be Microsoft then) will release a browser that renders the majority of sites unusable.

So most web designers really don’t feel there is an overwhelming need to start developing sites using CSS based layouts and standards compliant code.

Changing the Barriers to Entry

One of the reasons the web has been so successful, is it’s low barrier to entry. HTML is a simple “language” to learn and browsers are very forgiving about poorly formed documents. This makes it incredibly easy for anybody to publish on the web. Even your 12 year old nephew could knock up a simple site using the copy of Frontpage that comes bundled with Microsoft Office.

Compare table based design to CSS based design. Sure the syntax of CSS is pretty easy. Nobody in their right mind would argue that you need too be a rocket scientist to learn CSS. However, some of the concepts can be quite tricky to grasp. On the face of it, the box model is pretty simple, yet I still get tripped up by margin collapsing on occasion. Floating and clearing can be conceptually difficult to grasp, as can positioning. In my experience, there is probably around a 6-12 month learning curve from knowing basic CSS to actually being able to develop CSS based sites competently.

Then there is the problem of browser support. Once you’ve been doing it for a while, you get to know what browsers support what, and what the common browser bugs are. However, there are so many bugs, even the “experts” find themselves spending an inordinate amount of time bug fixing. For a novice this must be extremely frustrating. Not knowing if the problem is down to your misunderstanding of CSS or some obscure browser bug. Is it any wonder why the same questions come up time and again on list like CSS-Discuss?

When the browser manufacturers finally get their act together, developing sites using CSS will get a lot easier. Still, I think most people would agree that CSS development has a much higher barrier to entry than table based design. In an odd way, I think this is one reason why CSS based design is becoming so “popular” amongst web professionals. It allows them to differentiate themselves from the amateur “FrontPage Cowboys” and take back the web for themselves. Perhaps this is why many people see web standards as “Ivory Tower” and why many web standards advocates come across as having a sense of superiority and a zealous attitude towards web design.

Some Things Are Just Easier with Tables

I’m sure we’ve all found ourselves writing fairly complicated CSS to do something that would be trivial using tables. Take form styling for example. It’s possible to lay out even very tricky forms using tables in just a few minutes. You can achieve similar results by floating elements with CSS, but it’s a lot more involved. |f you’re a CSS guru it’s all part of the fun. However if you’re a regular mortal and your boss is breathing down your neck because they don’t understand why their “simple form” is taking so long, it can be incredibly frustrating.

If you have the knowledge and patience, you can do most things using CSS that you used to do using tables. Sure it may take you longer, but you’ll get there in the end (or die trying). However there are some things which, try as you might, you just can’t seem to crack. One such thing is page footers. I regularly see posts from frustrated CSS authors trying to create page footers than “stick” to the bottom of the viewport if the content doesn’t fill the whole screen. It’s pretty easy to do using tables, but try doing this using CSS alone. Is it any wonder why web developers turn their back on CSS when even simple things are rendered so complicated when you stop using tables.

Overstating the Benefits

There are lot’s of good reasons for throwing away tables and adopting CSS based layouts instead. However in their rush to push web standards, many people have overstated the benefits. It’s true that switching a large site to a CSS based layout can save a huge amount of bandwidth. However, for most sites, this saving would be insignificant.

People want fast loading pages and many advocates have suggested that CSS helps accomplish this. For most sites, the “design” is spread evenly across the whole site. However with CSS based sites, the “design” is usually held in one or more external files. These files can be pretty complicated, and even for a simple site, can get big, fast. A recent site I designed uses 4 stylesheets weighing in at around 12k (albeit including formatting and comments). By using CSS you’re actually front loading the design, rather than spreading it evenly across the site. The means that the first page you hit can actually take longer to download than the equivalent table based page. Once the styles have been downloaded, they will usually be cached and not need downloading again. However the first page on a site is the one page that you really don’t want to see such a performance hit.

Client buy-in

The sad fact is, most clients don’t care how a site is coded. Yet for some reason web designers feel the need to “sell” web standards to their clients. One way people do this is through the carrot and stick approach. The carrot is more often than not, search engine friendliness, while the stick is accessibility.

It’s true that the search engines like semantic pages. It’s also a widely held belief that search engines like lean code. Building a site using CSS and web standards can definitely encourage the development of search engine friendly sites. However it’s no magic bullet. There are many table based sites out there that score very highly in the search engines. It’s equally possible to build a CSS based site that gets a terrible search engine ranking. The most important thing for high ranking is content and inbound links, not whether a site uses tables or CSS for layout.

More concerning is the number of people who try to sell web standards and especially CSS based design by playing on clients accessibility fears. There isn’t anything inherently inaccessible about table based design. As long as tables make sense when linearized, their content is easily accessible. Screen reader technology is pretty good these days, and most screen readers are proficient at handling table based sites. While it’s true that your site needs to be published to a recognised set of grammars to get a AA accessibility rating, tableless design is only a recommendation, not a requirement for the more stringent AAA rating.

One often mentioned benefit is that of supplier independence. In a world were everybody develops to a standard, it would be much easier to switch between developers. They’ll instantly understand how the site was put together and not have to trawl through somebody else’s tag soup. This is reliant on having a significant number of suppliers versed in web standards. Unfortunately this currently isn’t the case. While the number of skilled CSS developers is increasing, it’s still a relatively specialist field. Because of this, it could be seen as a relatively risky proposition for a large company to lock themselves into a style of coding when there is such a lack of skilled coders. In my experience an organisation will often have a single individual experienced enough to develop a site using CSS. For many organisation switching to web standards could actually increase their dependancy rather than decrease it.

Conclusion

Web standards and CSS based design are definitely the way forward. However in our rush to advocate these “new” techniques, we may end up believing our own hyperbole. Build something up enough and the reality will always fall short of our expectations. By taking a dogmatic approach we risk alienating the very people we are trying to convince.

Table based design will be around for a long time. To encourage developer buy-in we need to lead by example and help reduce the barriers to entry. Not create new barriers. We need to be honest and up-front about the benefits as well as the cost. Developing CSS sites can be hard and it can time consuming. In certain circumstances using tables for layout can make much more sense than CSS.

Comments (95)

London to Brighton Bike Race | May 11, 2004

My girlfriend has decided to do the London to Brighton bike race this year to raise money for the British Heart Foundation. As an example of a charity using the internet well, if you’ve registered for the event, you get your own sponsorship page on their site. You can email the link to your friends or post it up on your (or your boyfriends) website to get people to sponsor you. That’s what I call making the most of the web.

Comments (5)

Another Red Flower | May 11, 2004

red-flower.jpg

Comments (0)

Semantic Coding | May 7, 2004

The rise of web standards has also seen the rise of semantic coding. We’ve had it drummed into us a thousand times that <h1>’s are for headings and not for big text, that <blockquote>’s are for quoting text and not for indenting. We’re all so used to this now that we do it by default (don’t we?).

Semantic markup has been sold to us very well. The dream is that one day, other computer systems will see meaning in your code. Google will look at your headlines and think “hmm, that’s a headline, it must be important”. Speech browsers will see that something is wrapped in an <em> and will dutifully emphasise it. Using (X)HTML elements in the correct, semantic way is very laudable and long may it last.

If you’re a CSS author, you’ve probably used container elements to help control the visual display of your pages. You’ll wrap a <div> or a <span> around another element (or group of element) to act as a hook for your style. By doing this you’re adding meaningless markup to your code for display reasons. This makes you feel bad, so you’ll try to give these hooks some meaning. You’ll put all your branding code inside a <div> called branding and your main content will go inside a <div> imaginatively called mainContent.

You relax into your chair feeling glad that you’ve bought order back into the world. However, if you are anything like me (for your sake I hope you’re not) there will always be one or two rogue elements. For instance, you’ve decided to go for a two column layout. What on earth do you call their parent <div>’s? You could call them col1 and col2 or leftCol and rightCol but that just seems wrong. What if one day, via the magic of CSS, you decide to switch their position. Chaos would ensue and you’d be forced to hang up your web standards spurs in shame. Of course you know that you’ll never actually change the order, but it still niggles.

The question that springs to my mind is “does it matter?” Despite what we’d like to think, not everything has semantic meaning. Some things are purely presentational and sometimes it’s going to be impossible to completely separate meaning from display. While it’s reasonable to expect that current and future computer systems will be able to understand the meaning behind a <cite> element, is it reasonable to expect them to understand each individual authors personal semantic vocabulary? Because let’s face it, there really is no standard way of semantically identifying page elements outside the regular (X)HTML tags. As such, pretty much all this “semantic” information is meaningless. It makes up happy (and to an extent makes development easier) but it’s not really intended for anybody other than ourselves.

Comments (30)

Graffiti vs Stencil Art | May 6, 2004

Brighton has quite a bit of a graffiti problem. It was getting so bad that the local council devised a radical solution. Their plan was to go around spraying the words "is a plonker" next to the tags, in the hope that it would shame people in stopping. However the council have just announced that they are scrapping the plan. It's Mostly kids tagging blank walls. It's akin to littering or vandalism. It's pretty pointless and makes the local environment a much less attractive place to live.

However, there is also quite a surge in stencil graffiti, or stencil art. Rather than being destructive, stencil art actually makes the environment a much more interesting and quirky place.

Some stencil art is political. Highlighting issues in a light hearted way.

Bush Stencil Art

Sometimes it's quirky, like this zebra decal. Wild animals juxtaposed against the backdrop of the "Urban Jungle".

Zebra Stencil Art

And sometimes it's just fun, like this "Nurse Decal".

Nurse Stencil Art

Stencil graffiti is a mixture of gorilla art and anti advertising. Little subversive "blipverts" intended to interrupt the near constant assault of commercial marketing. And I think it rocks!

Comments (28)

Red Flower | May 2, 2004

close up image of a red and yellow flower

Comments (4)