Cascading Semantic Descriptions, or CSD, are my idea for a new way of expressing microformats. In my last post I talked about what was good about microformats and what was bad. Now I'm going to put forward my suggestions for how to fix them, and in the process make them a whole lot more flexible, useful, and powerful. Remember: the problem microformats are trying to solve is "how do we add semantic information to web pages?"

Semantic information is web metadata; it should act like it

Semantic information is a type of metadata: information about information. However, HTML has lots of other types of metadata already: in the HEAD of any HTML document you can have the META tag which can contain the information itself (e.g. keywords and descriptions) or you can have a LINK tag which relates the document to other documents, such as RSS feeds, or CSS. I think the most interesting example here is CSS, which is literally a document full of more metadata, specifically data about how the contents of the document should be rendered by the browser, visually or otherwise. One could argue that JavaScript is also a type of metadata, describing how the document should respond to user action.

There are a few important things to note about how existing metadata formats work on the web:

1. They are separate from the data itself, either in the HEAD or another document entirely
2. They are not HTML in nature. HTML is used to relate the document to its metadata, but the metadata is not itself HTML.
3. They are progressive enhancements, layering additional complexity and functionality onto the core document without significantly altering the form.

Thus microformats are an "unweblike" type of metadata in that they are none of these things: they are embedded into the content, they are arguably part of the document's HTML, and they necessarily alter the form and structure of the document -- not necessarily visually, but you have to alter your code for it to become a microformat. This already suggests microformats need to be reformulated.

Why be weblike?

There are a bunch of good arguments for maintaining the principles of web metadata I mentioned above:

1. Separate metadata is easily ignored, meaning it is more likely to be backward compatible. This is a key aspect of progressive enhancement in general.
2. A domain-specific syntax means metadata can be efficiently expressed. XSLT is the ultimate example of expressing a good idea in an unsuitable syntax.
3. There is less chance of technology conflict. If two technologies came along that both required rigid class name definitions as microformats do, it is quite possible they would conflict.
4. Keeping machine-readable metadata links in the document head instead of the body means they are also easily discovered and efficiently indexable. This is a key feature that microformats currently lack.
5. Technologies with a small in-document footprint are more easily retrofitted into existing systems. If you have a huge and costly CMS, the prospect of modifying all your markup and thus probably all your CSS to accommodate microformats is prohibitively costly. This needs to be overcome.

Furthermore, there is an excellent counter-example for the current formulation of microformats: presentational markup. Back in the 90s, we added tags like FONT and attributes like BGCOLOR to HTML. This solved the immediate problem but as pages grew more complex it created more: bulky markup, laborious maintenance, and an unpleasant mixing of content and presentation which made specialized web jobs (editor vs. designer) difficult.

Microformats need scalability

Microformats currently have the same problems, for the same reason: their creators are thinking primarily in terms of one or two microformat implementations on a page of HTML, discovered and used client-side by browser plugins and the like. If one wanted -- as really should be the goal -- to mark up every single piece of content on your page in a semantically meaningful way, layering microfortmats pattern upon pattern, your code structure would become incredibly rigid and the CSS required to arbitrarily display your content progressively more complex.

Two more points against: firstly, a search engine trying to index the entire web for semantic data would have to read your entire page, parse it, and then search it for all known combinations of all known microformats. On the scale of the modern web, that's a gigantic additional cost to the search engines that would hinder adoption. Secondly, in a reasonably large website, the people developing the software that generates markup are probably not going to be the people creating and defining the content of pages: to keep the jobs separate, you need a mechanism to separate semantics from structure, in the way that CSS separates it from presentation.

Goals of CSD

We want to add semantic information to web pages. Our solution needs to be:

• Lightweight
• Simple
• Easily adopted into existing markup
• Elegantly expressed
• Easily parsed
• Efficiently indexed

It should also, as much as possible, build upon all the excellent work that has already been done in defining microformats themselves and formulating existing patterns.

So with that in mind, you should head over to Cascading Semantic Descriptions at Emergent Web to read the draft spec document, learn from the examples, and more as I get around to building it all.