Burningbird's RealTech

You don't have to wait for Drupal 7 to RDFaificate your Drupal site. I spent yesterday tweaking my space, and if you access the site now with a tool, such as the Semantic Radar Firefox add-on, you'll see all sorts of semantic goodness. I used a combination of plug-ins and theme modifications to make my changes, and will probably add to the overall effect over time.

Read through for the gory details...

Tina Holmboe from the XHTML WG has written a concise overview of XHTML titled XHTML—Myths and Realities. She's provided a nice overview of the markup, including the purpose behind the development of XHTML and the state of XHTML today. The only somewhat jarring note I found about the overview is it seems that Tina went a bit out of her way not to sell XHTML. Perhaps this seeming "you should really need it before using it" push is the reality part of the topic.

I use content negotiation for my sites, serving up XHTML for those browsers and agents that can process XHTML, and HTML for the rest. I'm looking into embedded RDFa into my text in a new iteration of yet another site design, but my main reason for using XHTML is that I like to keep open the possibility of using inline SVG. I also think that support for XHTML seems to be broader than is implied by Tina, but again that could be her trying to downplay any hyperbole about XHTML—there's hyperbole about XHTML?

Though I know this is outside of Tina's overview, I would have like to have more focus on the differences between the HTML5/WhatWG stuff and XHTML 2.0. It's confusing that we have one group working supposedly on an "XHTML 5.0", and another on XHTML 2.0. Especially when one of the main issues to do with XHTML 2.0 was XForms, while a milestone reached with HTML5 recently was the incorporation of Web Forms 2.0—but don't let the "forms" that appears in both fool you into thinking we have any form of consensus or agreement.

A List Apart has a timely article titled Understanding Progressive Enhancement discussing the perceptual differences between graceful degradation and progressive enhancement. I enjoyed seeing Steve Champeon's idea given new light. Additionally, now is as good a time as any to have a go at these topics, with the many new enhancements being added to today's browsers, while antiques still cutter cyberspace. I could have done without the cloyingly cute M & M analogy in the article, but that's probably my inner Cranky Woman having a go this AM.

I've written about graceful degradation, previously. Graceful degradation means applying modern technology but ensuring the application doesn't negatively effect those viewing a web site with an Antique (remaining nameless). However, contrary to the ALA author's statement of Under this paradigm, older browsers are expected to have a poor, but passable experience, graceful degradation is just that: gracefully degrading, meaning that though the person using the Antique doesn't get all the bells or whistles, their experience at the site is more than "poor but passable".

Progressive enhancement, on the other hand, begins with the content, rather than the technology; ensuring that the markup used to organize the content is semantically correct and valid. Then, and only then, the web site developer progresses to the use of CSS and JavaScript, both to annotate and enhance the content. That's been the primary difference between the two approaches: graceful degradation tends to focus on technology, first, while progressive enhancement focuses on content, first.

After all these years, we have finally reached the point where we've separated page organization from presentation, and now we're about to embark on the same mistakes again, but this time with presentation and semantics.

I've been following the issues associated with the vocabindex Drupal module, including one where the person submitting the bug stated the vocabindex use of UL was incorrect. We're supposed to, MXT writes, use definition lists rather than unordered lists for any lists of terms with associated definition.

At first glance, it does seem as if the vocabindex module is using the unordered list incorrectly. After all, look at any of my category pages (such as the one for the Semantic Web)—what you see is a list of "terms" and their associated definitions. An obvious candidate for definitions lists.

Look more closely, though. In my sidebar menu I list the vocabindex terms as links to web page URIs, but there is no definition attached to any item. The description, if one is given, is, instead, added as a title attribute to the item and displayed only when the item has cursor focus. Yet, it's the same data. Does this mean, then, I'm somehow not properly displaying my menu items? Should I have a huge sidebar, with the item description given underneath?

More importantly, whether I have a given text description for each item is purely optional, some do, some don't. Yet the items in the list have meaning without any associated description. In fact, each item in the list is really nothing more than a label for a bucket to hold content. I could just as easily use foo, bar, silly, putty as labels, except that I'm trying to use "meaningful" labels in order to enable you all to better find past content.

In the absolutely ancient W3C page where lists are covered a list of ingredients is given as an example of an unordered list:

• 1 cup sugar
• 1 cup oil
• 2 cups flour

However, I don't see that anyone would have a problem with adding parenthetical information to this list in order to further clarify the items:

• 1 cup sugar (light brown granulated by C & H)
• 1 cup oil (canola or corn, but not olive)
• 2 cups flour (white or mixed white and whole wheat)

This is really nothing more than what the vocabindex is doing with the vocabulary index terms within both the index pages and my sidebar menu: a listing of items and a (parenthetical) description to clarify what that item is. However, it's only when the description is displayed as a "tooltip" that one sees the item as a clarification phrase, only. When presented in the index pages, it "looks" like a definition list, and so we want to have it marked up this way— mixing up semantics and presentation.

A definition list is assumed to have two pieces of information; the term or phrase and an associated definition. Even when not present, the definition is still assumed to be forthcoming at some point— not having it is the exception, not the rule. An unordered list is just that: a list of items. They can be a list of items to buy at the store, select from in a form, or click on in a web page. There's no assumption that any additional information is necessary for the item. If there was, Drupal would make this information mandatory rather than optional. The application and associated developers would definitely discourage the use of the items in a tag cloud or other format where only the term is given because the term, by itself, would be meaningless.

Yet we look at how the terms are portrayed in a page like the vocabindex page I linked above, and that's enough for us to say we should use one form of markup over another because it's more "semantical". Further exploration online at other sites who attempt to define the differences between unordered lists and definition lists shows the same thing: if we see two pieces of data, we're assuming a definition list, because that's what it looks like—not what it is.

The HTML5 document adds another key element to the discussion of definition lists by stating that definition lists are name-value pairs. From this can we deduce, then, that the name has no meaning without the value. That's my interpretation: that a definition list is the proper semantic markup only when data is defined within a context of names and associated values, both of which are meaningless without the other. If, however, *HTML5 allows us to list the names without values, or the values without the names, than the HTML5 document is imprecise, and we should just use whatever we want to use— semantics can not be derived from imprecision.

Currently in Drupal, vocabulary terms are discrete labels, nothing more. Any description is for clarification not definition, and isn't essential to the meaning of the term. Forget how the vocabindex pages "look", and focus on what the data means. If we can't do that, then this whole semantic markup thing is a bit of a farce, really.

*Confirmed: it doesn't