Coffee on the Keyboard » xhtml http://coffeeonthekeyboard.com by James Socol Fri, 20 Apr 2012 22:17:14 +0000 en hourly 1 http://wordpress.org/?v=3.3.2 Work Pattern: Designing Web Sites http://coffeeonthekeyboard.com/work-pattern-designing-web-sites-93/ http://coffeeonthekeyboard.com/work-pattern-designing-web-sites-93/#comments Mon, 26 May 2008 15:40:02 +0000 James http://coffeeonthekeyboard.com/work-pattern-designing-web-sites-93/ The premise of Design Patterns is that similar problems have similar solutions. In the same vein, I propose this Work Pattern a set of common steps I use when I create a web site, and maybe you can use, too.

Elements and Outline

My first step is usually to create an un-styled outline of a “typical” page. I fire up my editor, fill in the basic XHTML, and then go to work inside the <body> tag.

Most sites have this fairly common structure: header, content, footer. And just for fun, let’s throw in navigation between the header and the content. It’s pretty easy to represent this in XHTML:

<div id="header">
</div>

<div id="navigation">
</div>

<div id="content">
</div>

<div id="footer">
</div>

This is my first skeleton for >90% of the sites I design. It’s a very standard document. Sometimes navigation will be inside the header, but most often it goes like this.

Now you have to start thinking about what elements will be on the page. On this site, a blog, I used “articles” instead of “content” for the main div. I also added two side bars, and I knew that inside the articles div I’d want, well, articles.

<div id="header">
  <h1>Page Title</h1>
</div>

<div id="navigation">
  <ul>
    <li>Link 1</li>
    <li>Link 2</li>
  </ul>
</div>

<div id="articles">
  <h2>Recent Articles</h2>
  <div class="article">
    <h3>Article Title</h3>
  </div>
</div>

<div id="theblog">
  <h2>Sidebar heading</h2>
  <p>Sidebar paragraph</p>
</div>

<div id="theworld">
  <h2>Sidebar heading</h2>
  <ul>
    <li>Sidebar</li>
    <li>list</li>
  </ul>
</div>

<div id="footer">
</div>

An Un-Styled Skeleton

I won’t bore you with more code examples; I think you get the idea. I make an outline. I know at this point that my source is nice and valid, and that it will make sense when I turn off the stylesheet. I use semantic names for everything.

It’s not very pretty, but I now have a workable XHTML document, with a properly-nested outline, and most of the important elements. Good for me, because now I can start to style them.

Layout and Style

Now, I know what visual elements will need to go on the page. I know what page elements I need to style. Now I’ll start creating a style sheet.

My first style sheet will contain a few basic HTML tags and the elements of my document. I could probably write an XML-to-CSS generator with how strict I am with this step.

Ok, one more code example:

body {}

h1,
h2,
h3,
h4,
h5,
h6 {}

a:link {}
a:visited {}
a:hover {}

#header {}
#header h1 {}

#navigation {}
#navigation ul {}
#navigation ul li {}

#articles {}
#articles h2 {}
#articles div.article {}
#articles div.article h2 {}

#theblog {}
#theblog h2 {}

#theworld {}
#theworld h2 {}
#theworld ul {}
#theworld ul li {}

#footer {}

One of my favorite things about this is it’s almost impossible for a mistake in one section to mess up anything else.

But obviously there’s a lot in there I can combine, can shorten. Almost anything that’s true for #theblog will also be true for #theworld in this case, so DRY, and keep things together as much as you can. But, when you’re just starting the style sheet, this is a good place to start.

As I’m going, I add a lot to the style sheet. I also add a lot to the XHTML template. Pixels get tweaked left and right and I swear at IE6, of course.

Building Templates

Once I have a complete, or near-complete, mock up, it’s time to start building templates for your CMS of choice. This is mostly copy-and-paste work at this point. Your #header and #navigation go into the header template. #footer goes into footer. #content goes in the content template.

See how easy that is?

Then you get to go through and actually add the template mark up. Whether it’s Smarty or PHP or ASP doesn’t really matter, you just replace your dummy text with the right tags.

Starting Out

I love this process, but there is one thing you really need for it to go smoothly:

You need to know what kind of content you’ll have. When you’re redesigning your blog, or building an in-house site, it’s pretty easy to know. When you’re working for a client, you may need to twist some arms to get this information. (I love this A List Apart article for advice on communicating with clients.)

One final thought: use comments. Any time I create a div, I wrap it in comments like this:

<!--begin #articles -->
<div id="articles">
</div>
<!-- end #articles -->

I usually use the CSS selector because it’s specific, so #articles, .article, and so on. These comments—which I left out here to save space—have saved me so much time and effort compared to relying on indentation that I can’t imagine working without them.

I didn’t set out this process as a way to streamline my work, but rather, as I started noticing patterns that worked well, I started thinking about the process. Much like Rails, which was already running Basecamp before it was a framework, I’ve been using more-and-more-polished versions of this work flow for months.

Maybe you’ll find it helpful, maybe not. Maybe you already have a “system” in place. If you do, what is it?

]]> http://coffeeonthekeyboard.com/work-pattern-designing-web-sites-93/feed/ 2 The W3C Sucks http://coffeeonthekeyboard.com/the-w3c-sucks-92/ http://coffeeonthekeyboard.com/the-w3c-sucks-92/#comments Thu, 22 May 2008 22:54:53 +0000 James http://coffeeonthekeyboard.com/the-w3c-sucks-92/ “If you wish to be a success in the world, promise everything, deliver nothing.”

If you want to remain the standard-setting body for the web, promise new recommendations, never deliver.

CSS 2.1 is not even a published recommendation. Off with their (the W3C) heads.

A decade ago, the W3C was actively working to improve the standards we designers and developers use every day. Sure there were some controversial things (HTML 3.0, XML 1.1) that never caught on, but at least there was discussion, thought, and sometimes even action.

The W3C started work on the CSS3 specification the same year they published CSS2—1998. Ten years later, CSS2.1 is still not technically a published recommendation.

Between 1995, when the W3C was founded, and 1999, HTML went from version 2, an RFC, to version 4.01. Where is 5? In January of this year it became a Working Draft.

When was XHTML last updated? 2001. The DOM? 2004. MathML? 2003.

What happened?

When did “do nothing group” replace “working group” over there? (Probably around 2004.)

I realize that implementing new standards is not trivial. I also realize that standards are crucial to the continued growth of the web—this site is valid XHTML and uses valid CSS.

However, without updates, these “standards” will get old and die. Something else, or someone else, will replace them. We’ve already used CSS2 for a decade. Will we use it for another? (I want my drop shadows! I want my opacity! I want my rounded corners!)

I lead with a quote from Napoleon, so I’ll finish with the French Revolution: Off with their heads. The W3C needs a change in leadership or a vigorous shakedown to get off their asses and do something.

If they’re not willing to put forth the effort, then let them eat cake while someone else does.

]]> http://coffeeonthekeyboard.com/the-w3c-sucks-92/feed/ 0