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. :)

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

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!

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.

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.

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

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!

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.

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>
   <Dimensions>
      <Room name="Hallway" width="3.5" length="6.1"/>
      <Room name="WC / Cloak” width="2" length="3"/>
   </Dimensions>
</Property>

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.

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

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.

<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.

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

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.

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.

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

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.

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.

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.

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

Sigh.

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.

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.

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.

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.

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.

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.

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.

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?

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

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

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!

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!

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

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

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!

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

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).

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?

Hi, Just wanted to let you know that this page looks broken in IE6/XP after the entry by ‘Steven
Wed 7th 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).

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