Digital Web Magazine

The web professional's online magazine of choice.

Markup as a Craft : Comments

By Garrett Dimon

January 8, 2007


Gilbert Lee

January 8, 2007 11:34 PM

Great work, Garrett! I especially like #9. I find it easier to remember classes and ids when they are named appropriately. My CSS file may be a bit larger because I want to name elements correctly but I find it easier to maintain and gives me more control overall. Thanks for the article.


January 9, 2007 1:11 AM

A great article as always Garret! I especially liked number 20. I use tables to rarely that I completely forgot about the tbody and thead things.

mark rushworth

January 9, 2007 3:52 AM

I wholeheartedly agree… tho i believe in purity of code too and dont go in for any fancy formatting, use of tabs etc!

Andy Ford

January 9, 2007 10:00 AM

Brace yourselves…
I can hear the rumble of the legion of the Knights of the Layout Tables ready to come out of the woodwork to attempt to explain how their code soup is so much easier than dealing with some big complex scary css…

...seriously, Knights, if you can manage to wrap your brain around that mess of layouttablesjavascriptinlinestylesandspacergifs, then you can handle a little css – and you’ll never want to go back.

bravo, Garrett

Cody Lindley

January 10, 2007 6:13 AM

Garrett, nice read. If you don’t mind I would like to run a dilemma by you that I have been having concerning inline styles. In general, how do you feel about the use of inline styles? More specifically, the use of inline styles for minor adjustments, or styling that is only required once? Should we dogmatically never apply inline styles? Or are there times that inline styles will allow us to keep our CSS files clean, and add single event flexibility back into our HTML (like attributes).

Garrett Dimon

January 10, 2007 10:36 AM

Cody – The only time I can personally imaging using inline styles is for extremely unique instances where server-side manipulation makes more sense than creatinga plethora of external classes and changing them accordingly.

It’s rare, and I’ve never needed to do anything like that, but it’s the only instance where I’ve ever thought it might be better to go with inline. At the same time, if I ever came up with a need to do something like that, I might think twice about whether it really was valuable.

As for inline styles that are only applied once, I think it’s going to be more of a philosophical decision. It’s one of those things that could easily grow into a mess. I really believe it’s usually in the best interest of the code to put things where they truly belong, but I’m generally a purist in that sense.

It’s really what works best for the situation, and there will always be tradeoffs. I just haven’t found any instances that present a strong enough case to fall back on inline styles.


January 11, 2007 8:17 PM

Good points all. Isn’t it nice when we sit down after work with a beer and contemplate the niceties of code.

But when I get back to work and have 12 hours of work to do in 7 things aren’t quite so clear.

Clients want just one word in a paragraph larger, green and in Century Gothic. Is it worth crafting yet another style or just putting it inline?

Or that callout that the customer wants to overlap the containing div. Write yet another style or plop an absolutely positioned div and write the styles on the page instead of the stylesheet. It’s going to change next month and the next after that again and so on. It’s much, much faster to write an in-page stylesheet than to carefully craft another specifically id’d div in an external sheet, the have to go back and delete it with the next page revision.

The same goes, only more so, with embedded image in the page. It’s nice to write them in as a background for yet another custom div. Or just use Dreamweaver to replace the thing. I’m going to have to do so anyway next update. Images are reusable but having dozens of custom backgrounds is both time consuming and quickly clutters up your CSS.

If web pages are going to be kept the same for extended periods, fine, completely separate presentation from markup. But in the real world of deadlines and frequent updates, it isn’t faster, cleaner or practical to do so, not even close.

I have 9 sites in my client list I have to update monthly and 2 that update weekly. There are another three or four that need several updates a month that don’t give me the benefit of maintaining a regular schedule. That’s with two sites in the final stages of deployment and three more starting.

I’d love to have the luxury of finely crafting each site with beautiful code. Clean and lean, yes. Well structured, yes. Minimal divs, tables only for tabular data, yes. Div named for function and not display, yes. Graceful degradation and progressive enhancement, absolutely. Those steps do enhance maintainability, ease cross browser snafus.

Replacing all images with backgrounds? I don’t think so. Dropping a few in-page divs, some inline markup that will all be erased with the next update, sure. It saves a lot of time.

It would be lovely to hand craft each page as a work of love. But I work in a busy design house that demands a bit of mass production. That means using Dreamweaver for maintenance and getting this, first of several today, update in and out as fast as possible. Damn the elegance or lack thereof.

Don’t even get me started on maintaining sites we have to maintain that were created elsewhere in Frontpage.


January 13, 2007 7:26 AM

A great page. I’ll kindly ask if I can translate it into French and have it on some site of mine.

BTW, if the title of the article “Markup as a Craft” is enclosed in a H1 tag, shouldn’t the guidelines titles be enclosed in H2 tags (and not in P STRONG). That would help semantics and enhances the page’s accessibility.

Regards for the great work anyway,


Garrett Dimon

January 13, 2007 7:47 AM

Michael – There’s always tradeoffs. In many cases, it’s not really that much more time to do something correctly. The problem with taking shortcuts is that they build on top of each other until the code is incredibly difficult to maintain.

If you’re working with a site that won’t be around in 6 months, you’re absolutely right, it’s probably not worth it. When it comes down to it, we are talking about a business, and the goal of a business is to do that which is profitable and make money. However, sometimes the profitable decisions are long-term investments, and other times short-term investments.

The point of this article isn’t to dictate how one should run their business. It’s about painting a picture of where we should all be aiming for if we truly take pride in our work. Really though, very little, if any, of what the article discusses would actually require such significant additional effort that it isn’t worth it.

Marino – Translate away. :) Just make sure to link back to the original. As for the semantics, that’s out of my hands as a lowly writer, but it’s worth checking into.

Carolyn Wood

January 13, 2007 11:31 AM

Hi Marino,
Garrett’s guidelines aren’t headings. In other words, his information about a guideline doesn’t follow the guideline. Sometimes it does, sometimes it doesn’t, and sometimes the guideline is in the middle of the paragraph that discusses the guideline. If the description of the guideline followed the guideline, then, yes, we would definitely make the guideline a heading.
Glad you liked the article!

Andy James

January 14, 2007 6:12 AM

This article is comprehensive and brief at the same time! The guidelines are formed in a nice order that helps to apply simple practice. Thanks Garrett!

Garrett Dimon

January 15, 2007 7:40 AM

Carolyn – I feel stupid now. I completely forgot how I wrote the article. I suppose if I had thought about it for a second, I would have remembered that.


January 15, 2007 7:56 PM

Garrett – if your goal was to paint a picture of the goals to which we should aspire, you did a great job :-).

I guess it’s a matter of knowing when to do it right and when to save time with a hack.

When I create new site templates, either for a CMS, blog or for Dreamweaver I make them as clean and elegant as possible.

When pages get continually written over, as on a new attractions page for a movie theater, if there is a custom tweak, it’s often faster to do a quick and dirty inline edit. The page skeleton is well made, but some of the clothes the document is wearing are a bit thin and held in place with safety pins. I think of it as the kind of quick wardrobe change that actors have to do on stage. Get it on and then replace it as fast as possible. It only has to last a week or three. Hacks don’t compound because the content will be completely replaced in the next edit.

But you’re absolutely right that if the underlying HTML isn’t solid, even elegant, then problems multiply quickly.


January 15, 2007 10:18 PM

pretty work,i have made a chinese version中文版 here

Tanie linie lotnicze

January 19, 2007 3:22 AM

Fantastic article covering some points I really needed some good usability info for.
I especially liked number 20.
The Garrett’s guide link in particular was especially useful.

Best regards from Poland


January 19, 2007 8:15 AM

Great article, straight to the point and well summarised.

Dimitry Z.

January 23, 2007 12:00 PM

Good summary of practical and meaningful CSS practices. I would like to add a point:

22: Read over the XHTML a second time and simplify even more.
In complex designs, the habit of over-marking is natural. You don’t want to go back and forth between the CSS and XHTML to make adjustments, especially in 2+ member teams, or when elements on one template occur on another. However, this often leads to bloated markup that, often time, is heavier than the table layout you started of with.

There have been experiments in complex layout using JS to add wrapper elements for drop-shadows, rounded-corners, etc. Definitely worth checking out.



April 14, 2007 7:15 AM

While what you say appears to be right on and in fact useful, I think it’s very hard to take you seriously due to all the layout errors!


April 14, 2007 1:49 PM

The author has probably never worked seriously with HTML emails, because some of this advice is utterly wrong for them.

Different email clients vary widely in their support for modern HTML features, so e.g:
(1) you should use tables for layout and
(2) use inline styles, never use linked/embedded.

Don’t believe me? Copy-and-paste your state-of-the-art Web page into an email and send it to someone who uses Lotus Notes or GMail.


April 15, 2007 11:32 AM

interesting, how much is being written on this topic, and how little done to achieve the goals..

Dustin Brewer

May 6, 2007 2:01 AM

I don’t think that anyone could write enough about mark up. It is our industry and their are no ends to how much can really be said about it.

mark rushworth

May 10, 2007 8:33 AM

I go to great lengths to craft my markup – tho i HATE nesting code… its just a waste of space to me. One tip i use a lot is doubling up on classes i.e. class=“foo bar” which helps. also if you’re doing a small/static site then it pays to create one master page that contains all the markup for the entire site and its content… it helps you work on a single stylesheet until you’re ready to break the design apart


May 17, 2007 4:44 AM

@Dustin: Totally agree on that one.


July 20, 2007 2:00 AM

Although I like the microformat approach I’m still not sure if it is the right way to do it. Using class attributes is not semantic, no it’s definitly not. Only XML would solve this problem but we are still in an HTML world which is far away from semantics.

Sorry, comments are closed.

Media Temple

via Ad Packs