On the AJAX-driven Web, Plain Old Semantic HTML Can Help
For those of us working in specialized industries, investing in the strict microformat standardization process for most of the data we trade in is a lofty goal, with little reward. Microformats are standardized to encourage the browser and other software to apply behavior to the marked-up data (say, extracting a vCard and adding it to your email client). Furthermore, they’re generally, if not necessarily, used to mark up very common data—what customer facing website doesn’t have contact information?—not industry- or application-specific data formats.
(Please note that these examples all assume Ruby on Rails and jQuery and are wildly simplified.)
Moreover, I would have already spit my data into the view (HTML) file when I generated the markup. I’m only making one database query, but I’m printing my data to the template twice. I’d like to avoid this redundancy.
Make an AJAX call after pageload:
There’s another solution, which involves generating JS files on the server side, but since the data I’m trying to get from the server may be different on a request-by-request basis, I’d have to generate the file on every request, rather than compile it once at build or deploy time. This would inhibit or eliminate the possibility of caching, so we can give a pretty definitive thumbs down to this approach. I’m only mentioning it for the sake of thoroughness.
According to microformats.org:
the term “poshformats” distinguishes these one-off, ad-hoc or more informal class-name based formats efforts (based on long-standing modern web design POSH practices) from the more formally researched and documented microformats.
A poshformat looks like a microformat, but it hasn’t been defined and vetted with as much rigor.
For example: The markup (poshformat)
Say I work for a website that analyzes baseball statistics. I’m always displaying players’ stats and information on my pages, then doing all kinds of fancy AJAX-y things to these player representations. The POSH markup for one of these player representations might look like this:
What we have here is a “poshformat.” According to microformats.org, “When the author of that POSH declares it to be a ‘format’ of some sort, then they’ve created a poshformat.” Well I just did.
For the sake of simplicity, the “player” instance above only includes a name, a photo, and some “vitals.” But it could easily include basic stats, like batting average, hits, and runs, plus advanced stats, like OPS and VORP. Good poshformatting is perfectly extensible.
“But I’ve got the HTML5 itch!”
“That’s what this is, right?”
Well, sort of.
Regarding data-* attributes, the HTML5 specification says this:
Custom data attributes are intended to store custom data private to the page or application, for which there are no more appropriate attributes or elements.
These player data will appear in search engine results; they may appear in an RSS feed. In other words, they aren’t private. However, what I have isn’t a microformat or RDFa; the labels I provide to it are not for the benefit of these or any other applications outside my page.
A microformats.org article, Microformats in HTML5, says this:
Note that the data-* stuff is explicitly not for microformats. […] They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does. There may be some cases of private poshformats that are never intended for interchange that may be used in data-* attributes.
We’re getting some mixed signals, but they seem to be pointing towards sticking with good old classnames.
JSONifying our poshformat
The POSH way
A note on Skytap’s use of this technique: SmartClient presents a tricky problem: it is possible to open SmartClient for an environment that has no VMs, but to which VMs could be added by another user or from another page. If SmartClient loads with an empty environment, there is no poshformatted data from which to gather the structure of VM data. In such cases, we reload the page after the first VM is added.
The astute reader will point out that the above code is extensible only by adding additional lines of code and not very generic either. That’s true. The next step is to develop a generic way to define a model and automatically extract instances of that model from the poshformatted DOM.