Semantic Typography: Bridging the XHTML gap

November 24th, 2005

Semantic Typography: Bridging the XHTML gap

In the Web Standards community we hear the words ‘Semantic Markup’ thrown around a lot as a concept—the right thing to do— but I know a lot of designers who are trying to learn this stuff are being confused by the whole ‘semantic thing’.

It’s a difficult task for a designer, who primarily thinks very visually, to relate to a concept like semantics in a document when all they want to do is create something.

After doing a ton of research over the past couple of weeks I’ve begun to notice links and patterns between typographic theory and Web Standards.

I’m going to keep this quite brief and hopefully practical from a design and development point of view.

First of all, I’ll explain some of my thinking.

Typographic structure

In most documents there is a typographic structure and a hiearchy of elements, from letters up to chapters. Here’s a list, which is by no means complete, that explains what I’m on about:

Words → Sentences
Sentences → Paragraphs
Paragraphs → Sections
Sections → Chapters
Chapters → Document

You could of course go more granular than this, but I think it illustrates the point.

From this you can see how, by looking closely at the content, that the language can be broken up into chunks, into bits of semantically functional elements. So, you could argue that:

Documents have a conceptual structure
Graphic structures can be made that reflect conceptual structures

This perhaps the key to successful typographic design. Making sure the graphical representation of the content matches the mental model of the reader, or conceptual structure stipulated by the author (or preferably both).

Bridging the XHTML gap

As I mentioned earlier, designers often struggle (in all the Web Standards malarkey) to make the connection between their design, the content and then the code. The code bit seems very abstract initially. Hopefully this next stage will help explain how the gap can be bridged painlessly.

We have our model for matching the semantics, or meaning, of our document to the design we create:

Documents have a conceptual structure
Graphic structures can be made that reflect conceptual structures

Now, add to that our step for XHTML:

Documents have a conceptual structure
Graphic structures can be made that reflect conceptual structures
XHTML structures can be made that reflect conceptual structures

So:

The graphic and XHTML structure of a document should reflect its conceptual structure.

Therefore our finished web page will:

Be presented, typographically, to match the document’s conceptual model
The XHTML underlying the web page will also match the conceptual model
The meaning, or semantics, of the web page will match that intended by the original document.

For the visually oriented amongst us…

I’m going to put this into pictures to help explain what I’m on about. If anything it might help me firm up this theory a bit.

So, let’s put this in the realms of reality. Let’s say you have a brief from a client, who happens to be an estate agent, to build a web site for him. Most of the content for that site will be house details. Currently he produces single sided documents with the house specs on and he wants you to build the bulk of the website using this information.

So, here’s the house details:

{title}

As you can see, there’s very little visual design been done to this document. The first task then is to establish the document’s conceptual structure, its semantic elements, from there we can identify our typographic structure.

{title}

Once that is done, forgetting the design for the moment, we can (again, using the documents conceptual structure), label those elements with their corresponding XHTML tags.

{title}

The document conceptual structure is retained, we now have our XHTML structure (our semantic markup). Focussing then on the design we can make the typographic structure match the conceptual structure (still retaining our XHTML structure)

{title}

And there we have it. A typographic design, which has been tagged up with semantic XHTML, which retains the author’s conceptual structure.

The benefits

The benefits of going through the process in this manner is that it’s from a designer’s perspective, there’s less of a leap conceptually into the land of code where document structures are common place (OOP etc.) I’ve been following this model for a couple of weeks now and it works pretty well. It streamlines the process of assigning heading tags for example which have always been quite arbitrary in the past.

For those designers who are coming from a multi-disciplinary, or print, background and have trouble with this whole ‘semantic markup’ thing, please give this a go and let me know what you think. In fact designers who have been doing Web Standards for a while please give this a go and let me know how you get on with it. I’d be interested in knowing your thoughts.

This entry was posted on Thursday, November 24th, 2005 at 10:11 am and is filed under CSS, Design, Typography.

You can follow any responses to this entry through the RSS 2.0 feed.

Responses are currently closed, but you can trackback from your own site.

Paul D said on: November 24th, 2005 at 3:08 pm

This article is a very good introduction to what web designers mean by semantic mark-up.

In truth, you could probably fill a whole book exploring the relationships between semantics, typography, and XHTML, and how good typography and code achieve better communication.

Also, kudos for using the right-arrow glyph. :)

Danny H said on: November 24th, 2005 at 5:15 pm

It?s funny because I have been doing this same very thing, but haven’t realized it. You articulated what I have been working out in my head all along since I got into webs standards.

Now I can think about it in a more analytical fashion, with my new-found awareness.

Great article

Marc Jones said on: November 24th, 2005 at 7:11 pm

My HTML/Web design ‘skills’ are not only self-taught but also until recently old skool until it hurt. Of course I appreciate the argument for semantic CSS etc but I think what has been difficult for me in seeing the light has been thinking in the correct manner. CSS/XHTML from a learning POV is awash with code-first type of teaching — this example is another “moment of clarity” for me on my journey to a better web.

Far from code being abstract at the start of the process I think it can also serve as a mental block — ie almost stiffling free thought in a design sense. A sort of “but how do I achieve” scenario.

The example used above puts the actual semantics into their rightful place and pave the way for designer-first-code-monkey-second types to “get” the end product (code-wise) enough to design accordingly but without feeling shackled (in my case at least).

As it happens I am about to redesign an estate agent’s website I built 2 years ago using what is now an over proliferation of table-based nastiness.

Ain’t it great when things seem to fall into your lap just at the right time!

Galen said on: November 24th, 2005 at 10:51 pm

Mark, I’m very impressed with the content of your articles. It’s nice to find a blog that has good, quality information that keeps things simple.

I’ve been making a concerted effort to use structural?or semantic?markup but this article has certainly made the concept more straightforward and understandable.

Keane said on: November 25th, 2005 at 1:46 am

Where I struggle with semantic markup is with the grey areas. Perhaps it doesn’t really matter, but, for example, in your example, why is the list a list and the table a table? As far as I can tell, the list _should_ be a table (I certainly don’t think it’s a definition list), but because the original author has made it a list, you’ve made it a list. Perhaps I’m straying off course into content editing here, but in the context of semantics …

Um, anyway, and staying firmly on the pedant’s pedestal, what’s the semantic and/or typographic point of the NEW! star? It’s not in the original article …

p.s. I should say, having opened up with a volley of criticism for my first comment on your site, I do love your writing—your five simple steps to better typography articles hooked me (and the comments directly led me to purchase Bringhurst), though I’m yet unconvinced by the ‘hang your punctuation in the gutter’ theory. That said, since reading that particular article, I do make a conscious decision to push my bullets and numbers as far left as my stomach can handle. So you never know—before long, I might well be dangling them out there too.

Heiko said on: November 25th, 2005 at 9:47 am

A very good little tutorial for semantic XHTML structure. I will choose it as my article/site of the week at my blog. Thx

Wible said on: November 25th, 2005 at 3:03 pm

Well thank you — that was very clearn and it demystified something for me. I’ve been trying to make my (current) code clean and arranged neatly but you put a whole now spin on things for me here. Thanks… and now I ‘get’ the whole semantic thing — I hope!

LintHuman said on: November 25th, 2005 at 3:38 pm

An excellent and succint summary of a structural approach that puts content at the heart of the matter.

So many clients want us to produce visuals without providing the content, thinking that it can poured in to a design once it’s in place. Trying to explain to clients that you need the content before you start designing too often provokes looks of confusion.

Your example cleverly shows that we’re working in the dark without it. Great stuff.

Chris said on: November 25th, 2005 at 3:40 pm

From a ‘web developer’ POV — This ‘conceptual structure’ is also known as an XML document. The above example could look like this:

<Property>

   <Name>19 Meadow View</Name>

   <Overview>

      <Price>300000</Price>

      <Bedrooms>4</Bedrooms>

   </Overview>

   <Image>123432.jpg</Image>

   <Description>Individual family house…</Description>

This XML documentis purely about data and has nothing to do with presentation or HTML for that matter. But even at this level we can begin to get ideas about how this data would be best displayed. E.g. what should be a table, what should be a block of text etc.

Also this ‘conceptual structure’ or xml documentis a great way of communicating with your respective programmers.

Great article (yet again) Mark and backs up your case for information driven design.

Jason said on: November 25th, 2005 at 9:10 pm

Thanks for posting this. It will definitely come in handy.

Rick H said on: November 26th, 2005 at 2:25 am

Adding to LintHuman’s comment: Your example, while very well explained, brings up a problem when writing (and designing for) semantic content. Given that the main heading (from a typographic or a conceptual point of view) is more or less supposed to be descriptive of the page content, exactly what is “19 Meadow view”? A street address? Maybe an address in a well-known development that I should be familiar with? Why is it important? My opinion is that a new h1 should be written that is more descriptive and the current h1 demoted to at h2 or h3 at best. It’s still necessary to have good, well-written content.

Mark Boulton said on: November 26th, 2005 at 11:43 am

Chris — A really good point. I hadn’t thought about the xml structure as well.

Rick H — I take it you’ve never had to go through six months of trying to find a house ;). The address of the property is the most important heading on a page like this, without doubt. What would you suggest instead? What could possibly be more descriptive about a property’s location, or unique identifier, than it’s street address?

Although your comment is a good point, it does highlight where people can get confused with this.

patrick h. lauke said on: November 26th, 2005 at 2:12 pm

<blockquote><p>What could possibly be more descriptive about a property?s location, or unique identifier, than it?s street address?</p></blockquote>

mark, it’s not about a unique identifier for the property, but about an unequivocal title for the page itself. imagine you come to the page from a search and wonder “what’s this page about?”. you look at the H1 and all you get is “19 Meadow view”. fair enough, you could correlate, based on the page’s TITLE, that it’s details for a property…but far more explicit would be something like “Property for sale — details” (being a bit wordy here to make the point) as an H1, and the address as an H2.

of course, just looking at this fragment in isolation is not very indicative…it may well be that the overall structure of the site/page around it may give more details and context.

Mark Boulton said on: November 26th, 2005 at 3:14 pm

Patrick — I take your point, well put. Like you say though, we really do get into the semantics and usage of particular tags for particular things, like the page TITLE.

Should the H1 be the page title? Or should it be the TITLE (as intended by the HTML spec I’m guessing? If it’s the former, are we designing to the way search engine’s work rather than being true to the documents conceptual model. A page’s title is dealt with (or rather should be) by the page’s TITLE.

Like you say, the context is very important. In the context of a section on houses for sale in an estate agent’s website, this content would make sense. Take it out of context and things start to change.

Yannick said on: November 26th, 2005 at 3:34 pm

Very nice article Mark. Will definitely give it a go in my next project.

Ara Pehlivanian said on: November 26th, 2005 at 5:02 pm

Great article. I’ve gotten so used to thinking semantically that it’s hard to approach a documentotherwise. You’ve really done a good job of covering the designer’s perspective.

Erwin Heiser said on: November 26th, 2005 at 5:43 pm

Nice article, mark, it reminds of so many clients who contact you and go “I need a website”, more often then not they are clueless as to what they are going to put on that website. As ever (well-structured) content is king.

Jon said on: November 26th, 2005 at 10:34 pm

Good stuff Mark. My HTML code monkey made me read this and threatened to forward all hyperlinks to naughty sites if I didn’t.

I’m the visual guy—the design monkey, so I can respect where you’re coming from.

However, like the analogy given, there are multiple ways to ‘correctly’ format a paragraph or a line of thought. Or, for that matter, a design.

Similarly, there appears to be multiple ways to ‘effectively’ produce a line of code that works.

Now, I’m all for the most efficient methods, but there’s a line between “efficient” and downright anal in my opinion.

I have a copy guy who is anal about his copy and the HTML guy can’t understand why.

Same thing guys…we’re all trying to produce the most ‘effective’ (rules notwithstanding) page. Sometimes that may call for ‘poor’ mark-up, such as underlined text, to make the function of the page (a sales page, for example) work better. That’s the debate right now, so I figured I’d toss it out.

Personally, I dislike underlined text ‘most’ of the time when it’s not a link. However, it’s a clever trick for marketers to use, and if “efficiency” is really the goal here (and it should be) then mark-up needs to take a back seat.

On the other hand, a gob of horrid code to create a certain look—well, I can understand why that is the work of the devil.

Thanks for the insights…Jon

mattymcg said on: November 26th, 2005 at 11:16 pm

Great article Mark. Like Keane and others though, I think that clearly delineating what is conceptually “more important” is a big grey area that is poorly defined by the W3C and consequently interpreted differently by different designers. For example, where would a page’s global or local navigation fall into this hierarchy? Do they also need headings? Are they more or less important than the existing ones? What about visitors using screen readers, do we need to give navigation a title for them because they lack visual context, but hide it for everyone else? These types of issues make what should probably be a well-defined process more like a can of worms.

Anyway thanks for making a small chunk of it clear, it’s a good place to start.

Ray said on: November 27th, 2005 at 1:05 am

I’m Jon’s HTML guy.

I understand why the client (sales guy) is anal about his sales letter. He’s making money.

Thanks for illustrating the typical void between marketing and markup though Jon. Markup should *never* take a backseat to effectiveness of a sales page. In fact, a poorly marked up documenthurts a sales page’s effectiveness. Why? Because a documentthat is not semantically rich will not return any sense of relevance to a search spider. And in search visibility, relevance is the name of the game. Markup is life.

Underlined text isn’t the issue here. That’s an abomination unto itself. ;)

Mark, nice article. It captures the process of turning the visual guy’s work into a Web documentrather neatly.

Jon said on: November 27th, 2005 at 1:18 am

I’m Ray’s HTML curse.

Markup should indeed take a backseat to effectivenesss. There’s the assumption that a page will not be ‘spidered’ if markup isn’t just “so”.

“Poor markup” could be described as “underlined non-linked text”, but this will in no way affect searchability of a site.

There are other examples, but I agree with the overall concept of this blog: clean markup and clean design should meet and marry. However, one should stop trying to kill the other—and effectiveness is still the ruling factor. If something works well, then it works well. If it can work ‘better’, then by all means let’s make it work better.

However, as a designer, I relate to the idea of “perfectionism” to a degree, and code gurus can often get so caught up in that pursuit that they lose site of the purpose of a page to ‘begin’ with.

Designers do the same thing.

So, while I’m not one to ever do crap design, I’m also not going to create Picasso for a tri-fold brochure. I will put my energies into the things that really matter—helping my client make money from the brochure.

Some of the worst brochures I ever came across from a marketing standpoint were works of art. The artist can visually pleasure him/herself all day long, but the client and the company is the one who pays—literally and figuratively.

Anyway, Ray and I actually see pretty eye-to-eye on this stuff. He’s just a Canook and likes to argue. I dig ‘em anyway.

Ray said on: November 27th, 2005 at 1:23 am

Note to self: never send a client to a developer’s blog.

Sigh.

nortypig said on: November 27th, 2005 at 1:59 am

This is one of the best ways of actually explaining to people what semantics is. Often the word just glazes over someone’s mind but I will send them over to read this in future. The first part might still be kind of difficult to grasp for someone never hearing of semantics before, but the explanations after that did make it clear as shiny chips and tomato sauce.

Outstanding article. Hey I love your comments, if only I were half as talented… awesome.

Wim Leers said on: November 27th, 2005 at 2:07 am

Great article. Involves enough details, but stays simple — thanks to your well-chosen example.

There are so many sucky websites out there, in the wild. And I’m not talking about Mr. Failure’s blog — there are plenty of ‘big’, highly rated visitors with a bad site structure.

inoodle said on: November 27th, 2005 at 6:54 pm

Nice article, I’m sure I commented on it on friday, but it seems to have disappeared! Anyway, I was wondering if you had any rules to decide when to use a list, and when a table, as semantically, they seem to be pretty interchangeable, at least in the example above.

Wim Leers said on: November 27th, 2005 at 8:09 pm

inoodle — In general it’s this rule: tables should be used when you want to present data with two dimensions, while lists should be used for single dimensional data.

inoodle said on: November 28th, 2005 at 2:05 pm

Wim, in the example above, both the list and the table really have the same dimensions. Its unfortunate but the choice often seems dictated by the visual requirements of the designer as opposed to the semantics of the information.

Jordi Pujalte said on: November 28th, 2005 at 5:15 pm

I think I see the criteria for selecting of a table vs. a list.

List:

>x-type thing: x-type thing details

>y-type thing: y-type thing details

Table:

>x-type thing: x-type thing details

>x-type thing: x-type thing details

So, the list lists a list of different, though related, items. A “prize” is not a “number of rooms”, and they are not the same thing as a “garage type”, but they are properties of the house.

The table of rooms, however, is listing a bunch of objects of type “room”, with each column describing a property of the given “room”, hence the 2-dimensionality.

In short, a list shows elements that are somewhat related to each other, whereas a table lists elements of the same type.

inoodle said on: November 28th, 2005 at 5:32 pm

jordi:

Yes I see what you mean, and I’ll try and apply that. However when looking at the example, it almost makes me question if the price should actually be part of that same group of information. The other 3 items of information relate to room details, and the price could be said to be a quite separate piece of information.

I suppose the items in the list are all likely to be stored as searchable items in the database.

Wim Leers said on: November 28th, 2005 at 7:05 pm

Or maybe… we’re just being over-strict on applying the correct semantic strategies. There is a point where information can be understandable and well-ordered in both a list AND a table. Shouldn’t it all be about making the data presented understandable instead of taking note of the slightest nuance in semantic difference?

WebtrafficJunkie said on: November 30th, 2005 at 1:49 am

Thanks for the information. It will definitely be helpful!!

Butter said on: December 1st, 2005 at 11:58 pm

Great article. Kind of reminds me the Information Architecture book i am reading.

Edd said on: December 2nd, 2005 at 1:01 am

Ignoring the dl/table debate for now.…Mark said…

<blockquote]>The code bit seems very abstract initially.</blockquote>

Semantic code is understood much better (by it’s very nature) than non-semantic code… I could teach my Mum (and Nan.…maybe!?) how to mark up headings, paragraphs, lists, etc, and she will have a clearer understanding of why than anyone ever did using non-semantic, table-ridden, bastardised yester-year code. She knows what a paragraph is…she was taught it at school.

By-passing the “visual” designer that the article addresses for a moment, if you take the design process back to the copywriter (whom ever that may be) it is likely that they will have envisioned the “creative” in much the same way as we, the web designers, would have marked it up…“headline goes here…copy goes here, list of stuff, etc”

The “visual” designer will take this copy and turn it into a “design”… they should therefore have an understanding of the meaning of the copy…Whether they can express it as such or not.

You can wring your hands all day about lists/tables/hX orders but the basics of semantics is not a web design issue, its about undertanding documentstructure. The tags are there to help! Ask my Mum, if you don’t believe me!

Steven said on: December 7th, 2005 at 4:40 am

You put the price and number of rooms in a definition list but what is the definition term?

Price?

Surely it should read -

<dl>

<dt>Features</dt>

<dd>Price..</dd>

</dl>

Or even just using an unordered list and having an h2 called features.

I would also suggest the street address is made into an h2 and the h1 be something like -

Houses — County — Town

Then if a search was made then you know that you are looking at a page about houses in that town and county with the subheading showing the street in that town and county.

Just my two pennies worth!

Anyway the article is excellent and will help me further!

Siegfried said on: December 7th, 2005 at 4:25 pm

Hi,

great article, indeed. Although i think it still gets too short. But the example is indeed really excellent. Starting by visually/grafically grouping the various parts is a very good start.

But then calling some parts simply “list” or “table” is not the way to go. Better is the version posted here using some kind of xml formalism. It makes a difference if you call the second block in this examle a “list” or a “property”. Calling an image an image (or depiction or whatsoever) is o.k., but the following is not a paragraph (what is a “paragraph” in content semantics?), it is a description. You where right when you stated that we should think of the “meaning” of a web page part. But then, what is the “meaning” of “table”? I could imagine of many “tables” containing thousands of different contents. But for this example i could only think of exactly one “Room Plan”. So this is not a table, this is a room plan. The table is only a (good) tool to organize, what the room plan really is.

If you then want to translate your semantic markup into (x)html, then you should use (x)html-Tags like li or table, but then still the class or id attribute should reflect your semantic markup.

Sorry for any broken english, maybe for saying that my english is not quite good enough.

Regards, and thanks for this article,

Siegfried

Steven said on: December 8th, 2005 at 2:18 am

dl

dt Features /dt

dd Price.. /dd

Posted again because dumbarse here put in the element brackets the first time, hence the silly looking post above…

Shani said on: December 10th, 2005 at 5:43 pm

Great article, but where can i learn to layout the page like that with css?

i usually use tables to do things like those.

Thanks ahead, Shani elharrar(male).

Graham Sanders said on: December 11th, 2005 at 7:21 pm

Hi Mark,

As expected yet another good article. Just wondering if you received the card I sent and if you were to do another article on Chritsmas cards as you did last year as I realy liked it?

Mal said on: December 22nd, 2005 at 1:19 am

Hi, Just wanted to let you know that this page looks broken in IE6/XP after the entry by ‘Steven

Wed 7^th Dec 2005 4:40 am’. Font is really big from there onwards and all on top of each other (I guess line-height is small).

Kuswanto said on: December 22nd, 2005 at 8:39 am

Very nice article. A lot easier to understand with the images.

Mark Boulton