Do we really need Microformats?
A lot of web developers, at least over the years, seem to have fallen for Microformats. Naturally, the given question then is: do we really need Microformats?
What are Microformats?
According to the Microformats web site:
Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.
Put in more plain English, it’s about marking up your (X)HTML with semantic and predefined class names and ids. If everyone uses the same class names for a certain type of data, we can write programs to parse it.
To read more about the reasoning behind it, read About microformats and why Microformats.
Let’s take three examples of the most popular Microformats:
<span class="tel"> <span class="type">home</span>: <span class="value">+1.415.555.1212</span> </span<
<div class="vcard"> <a class="fn org url" href="http://www.commerce.net/">CommerceNet</a> <div class="adr"> <span class="type">Work</span>: <div class="street-address">169 University Avenue</div> <span class="locality">Palo Alto</span>, <abbr class="region" title="California">CA</abbr> <span class="postal-code">94301</span> <div class="country-name">USA</div> </div> <div class="tel"> <span class="type">Work</span> +1-650-289-4040 </div> <div class="tel"> <span class="type">Fax</span> +1-650-289-4041 </div> <div>Email: <span class="email">firstname.lastname@example.org</span> </div> </div>
<div class="vevent"> <h3 class="summary">XYZ Project Review</h3> <p class="description">Project XYZ Review Meeting</p> <p> To be held on <abbr class="dtstart" title="1998-03-12T08:30:00-05:00"> 12 March 1998 from 8:30am EST </abbr> until <abbr class="dtend" title="1998-03-12T09:30:00-05:00"> 9:30am EST </abbr> </p> <p> Location: <span class="location">1CP Conference Room 4350</span> </p> <small> Booked by: <span class="uid">guid-1.host1.com</span> on <abbr class="dtstamp" title="19980309T231000Z"> 9 Mar 1998 6:00pm </abbr> </small> </div>
Does this really go all the way?
I’m a big fan of semantic mark-up, and having structure and value in the code. However, looking at various Microformats implementations, I think it’s valid in some cases, but just bulk code with non-semantic names in others. Well, why not add semantic value if you can, you might ask; especially since XHTML 2.0 doesn’t seem to be happening (at least not in a long time), and the semantic value added with HTML 5 is very sparse.
My reasoning is that, for one, almost every time you use it, you will get a lot of bulk code. Secondly, having your HTML code riddled with
span elements since there are a number of times when you can’t find anything more suiting, it doesn’t really enrich the code in my eyes. And, take a look at these class names examples:
- fn apparently stands for full name. Why not first name? Or function as many would interpret it? In Swedish, it’s also a short version of writing damn or fan (which means the devil). Not how I’d like to mark up a contact.
- Stands for organization, but could just as well mean organic or anything else.
- I think it’s highly unwise to use the exact name as a class name, that is an attribute of another element.
- I said, I think it’s highly unwise to use the exact name as a class name, that is an attribute of another element.
- Yeah, vEvent to match vCard. Handy, but it does feel a bit forced, don’t you think?
- Stands for date start. How about adding two letters, to get a real semantic value?
- Stands for date end. Again, how about adding two letters, to get a real semantic value?
- Stands for date stamp. Two more letters? Semantics, anyone? No?
One of the ironies here is that some Microformats supporters like to point to the W3C document Use class with semantics in mind. Would you say above classes really match that statement? And, overall, it would be so easy to actually make those class names a lot more semantic, but that ship has practically sailed since it’s been around for some years and everything is adapted to it.
And another thing which really annoys me in the above example code is using the
title attribute of the
abbr elements to display the date value for machines. For example:
<p> To be held on <abbr class="dtstart" title="1998-03-12T08:30:00-05:00"> 12 March 1998 from 8:30am EST </abbr> </p>
Do you use it?
What this all boils down to is two questions?
- Do you use Microformats?
- What do you think of Microformats?
you might want to read this:
This testing was done in the context of their BBC iPlayer.
(Also, I apologize for my typos and mistakes on the previous comment. It was written in a rush.)
I think "fn" stands for "formatted name". Some of the awkwardness arises because hCard can be used for a person, company, department, etc.
Also, my impression is that the class names for hCard and hCalendar are identical to standards dating back multiple decades, and they decided against changing them for the web.
Some microformats are much easier, including VoteLinks, XFN, rel-tag, and XOXO for marking up outlines.
And yes, I do use them.
Oh Robert, the title scared me.
For starters, yes, we do need microformats.
Like Michael as said, those aspects you're (sorry) picking on, is inherited from previous established formats (vcard and ical).
Also, just as it's written on that blockquote, it's a different concept from the Semantic Web of Sir Tim B-Lee… it doesn't require the production of external files (like FOAF or RDF), it aims to bring semantic value to the web we use today, using X/HTML to markup our data.
What you said about bloated code is partially true. As you become more and more familiar with the microformats you use, you'll realize that some of those generic spans and divs can be replaced with regular elements that are playing their part in your website.
You've missed out on several advantages as well… If you have microformats, say for an event, in your page you can use transformers to spit ready-to-use .ics files so that your users can import directly to their calendars, even if their browser isn't microformats-enabled.
(this actually works very well in the web today)
Not to mention all the pretty cool things you can do with this semantic value. Using xfn you can crawl a webpage and instantly build up a graph of someone's connections.
The other day I came upon an event over at last.fm in my hometown. It was at a obscure venue, but since they have their data marked-up with "adr" (http://microformats.org/wiki/adr) all it took was one middle-click and I was browsing google maps, pointing at the venue!
The beauty of it all is that it works with the web we have today. It may require an installation of an extension, such as Kaply's amazing Operator, but in a very near future we might not have to do that at all!
So Robert, even if the full blown Semantic Web becomes a reality, I still see purpose and use for microformats. The data is already there, microformats only tells you / parsers what they mean. 😉
The Fan notation made my day. xD
I use Microformats. hcard is excellent for a footer, since footers tend to contain contact information no always suitable for the address element.
I do believe it can be really handy when used right. That is, knowing when not to fall into any span mania trap.
The abbr-design pattern though, is pure evil. Can "this event is at two thousand four strike ten strike twenty one tee zero eight zero zero" really be at any help for screen readers (the sad part is that the above is no joke: WaSP has documented this madness in an available mp3 file).
Microformats are all about documented coding conventions. The process of creating every new one starts with looking for realâ€“world examples and researching how they presently are being marked up in order to bulletproof all possible use cases in the simplest way.
Similar approach applies to the class names. They are often based on other specs like vCard, iCalendar or ATOM to avoid inconsistency and confusion. Imagine situation when content isn't set in english and class names are the mix of two languages. In my opinion unified and more universal values like fn, org or dtstart *do* work better and mean more.
Microformats extend the capabilities of HTML and CSS but also highlight the limitations of existing technologies.
I personally think Microformats are a clever, low-effort way to make sites more useful.
I'm a big fan but ultimately hope there will be a cleaner solution. All those extra classes make me feel a bit sick!
AndrÃ©, even if it is not a problem right now, it doesn't mean it's semantically correct.
Can you really blame any future screen reader to do the wrong thing when spelling the title-attribute out loud when in comes to abbrevations?
I didn't used Microformats by now, because for lack of support. No Browser that i know supports Microformats automatically, which is a mess. And its difficult to explain to a customer, that it is absolutely necessary to implement Microformats, when nearly no one can use it by default…
BUT i'm not against it! And i will try to implement it in the future. It's an interesting field which should be supported!
Interesting topic. I agree that we may not need microformat.org microformats. I can't see how a centralised approach to vocabulary specification can scale with the needs of the web community. The microformats.org approach also make it difficult to mix vocabularies and express machine readable data without stuffing it in places where it wasn't meant to be.
Also, how do you know if a page is using microformats or just happen to use similar class names? It isn't unrealistic to use "vcard" as a class name…
But, if you take a look at RDFa you get a richer way of expressing semantics and there are already tools using it. RDFa is being included in XHTML 1.1, HTML5 and XHTML 2. And, it isn't really that hard to use it.
"fn" stands for "formatted name", by the way.
Oh – sorry Robert – Someone pointed that out already. Feel free to delete my comment 🙂
I, obviously, have a highly biased opinion on your article so I just scrolled down so as not to get baited into an argument.
Ole: Hang in there for browser support. It's on it's way. 🙂
As a side note: I do concur that you can end up with a bit of code bloat – but I think this technique makes the most of a not especially great scenario in the first place. Microformats lets you expand a language that's not all there in the first place. It's a bit of a trade of, but I think the additional richness is worth it (and the extra applications that come with that).
Although we're not supposed to think too much about the future, and concentrate on what we've got in the here and now, it will be really interesting to see how things stand up when HTML5 is completed and we've got a richer language in the first place. I envision "microformats lite" where a majority of the bloat will be repalced with new elements, and microformats will just be the icing on the top. 🙂
Short answer: yes I’ll use them and yes I think the markup can sometimes be a bit over the top.
Like George said above, for me, they’re a low-cost way of adding value to the page.
I like the idea of being able to go to a client’s or colleague’s web site and importing their contact details without having to look for them on the page – usually via my Microformats bookmarklet – sorry shameless self promotion 🙂 Equally with Upcoming or otherwise.
I agree that it's not very semantic but can you come up with a better way of marking up dates in a standard form?
If we take a step back, what's missing from the picture is for screen-readers to recognize that "title" as a date. So, what if JAWS and other prominent screen readers start supporting microformats as well? And why shouldn't they? All they have to do is implement the datetime design pattern, since the markup is telling user agents that the value in the title is a date. They can read it as a date as well "5th of June 2008 5pm". Plus, it's a great advantage to have semantic content highlighted from the page you're viewing, both in a regular browser and a screen reader. Just like they do with "headings" present in the document, they could notify the user there's "special" data in that page.
So, to sum up, while I agree with the distrust around datetime pattern, I don't see it as evil or as a show-stopper.
I've felt the same way about Microformats as you do, Robert.
I also think it's mostly useful for web-savvy public, regular Joes don't care less. Not that that is a reason not to use them on certain websites, but on the other hand, when facing a deadline, it's the first thing I'd drop from the project.
On the other hand, the second comment to your article, by AndrÃ© LuÃs, showed me Microformats can be cool in certain situations.
I haven't used Microformats in client projects, but I might do so in the future. Especially when dummy magazines and websites start publishing about them and the common man learns about their existence.
I think it'd be very useful if all Microformat class names were namespaced to avoid conflicts with other css, e.g. <code><span class="MF-locality">Palo Alto</span></code>
Ext JS namespaces all of their css and it is very useful in avoiding conflicts and as well in being able to tell which classes come from which library.
What you are describing is a prefix. It is not an ideal solution because it presupposes that the class name ("MF-locality") is for microformats only – which is not true. The idea is to reuse components and practise minimisation.
Microformats tries to work with what already exists out there (e.g., conventions, standards) e.g., "fn" is used instead of reinventing.
[…] Do we really need microformats? Robert Nyman is saying what a lot of us have been whispering about microformats for a long time – bulky non-semantic code riddled with excessive spans. Very good points all of them. Are you using microformats? […]
There is an underlying approach to solving common problems and having the opportunity to do it with minimal effort.
For instance, if we need to find a way to represent a content entry item (say something with a title, url, published date and a summary), we only need to solve this once – in terms of HTML – for a particular site. "microformats" just happens to give an outline (using classes/titles or whatnot) for the information that is based on widely adapted standards. Why reinvent the representation of a content entry item everywhere on the site where you can do it once and reuse?
Previously, we didn't recognise or found a need to outline particular types of information, so we didn't need the extra markup (relatively). Now we are able to recognise this information in our content and we mark it up. We also have a better way of introducing abstraction to HTML.
microformats may appear to cause "code bloat" but this is no more then writing templates that can work within a large set of cases/sites. The tradeoff is that, by going ahead with some abstraction there is a gain of having a multipurpose document. On the other side of the spectrum, less abstraction minimises code but makes the instances more unique to each case (having to write similar but different HTML – is this ultimately better?). The impression of "code bloat" in my opinion is caused by the contrast between the way of writing HTML.
Whether microformats is providing the best possible solution or not shouldn't make the final call in my opinion. It is not meant to solve all problems. The microformats approach still offers good development practices even with all of its "open issues". If it improves development time and maintains consistency with the added benefits of "microformat"ness, what is the real world problem here?
Hi Robert, you can see what I think about microformats here http://www.brucelawson.co.uk/2008/haccessibility-one-year-on/
The guy who points to the microformat mailing list posting called “The datetime screen reader problem is almost complete bollocks”, well: take it with a pinch of salt. One single screenreader user says he doesn’t configure his screenreader to expand titles. Big deal; do you base other design decisions on the prejudices of one user? (For example, if we made our fonts unresizeable because most users don’t resize the fonts in the browser, is that legitimate?).
I think most of the classNames are derived from LDAP-schema conventions, but I could be wrong.
They look basically the same.
And if we're on the subject of abbreviations, you're swedish Robert, do you know what a "GRDMAN" is in military lingo? Is it really an abbreviation when you remove ONE letter … ? 😉
Thanks for all your input! Also, thanks for “formatted name”, that makes more sense. I took “full name” from an article with Drew McLellan, but apparently he wasn’t correct then. 🙂
It’s encouraging to see that so many people are so involved and passionate about this. After reading your comments, I think my opinion stills stands, though. Microformats are great in some contexts, while they definitely have issue in others. Meaning, I might consider them in some cases, where I’d definitely refrain from doing it in others.
Regarding the discussion about the
titleattribute: while I agree with what some have stated above, that it will/can be a problem for screen reader users, it will, guaranteed, be a problem for everyone using a mouse and hovering over that element, resulting in a very cryptic tool tip.
And with RDFa and the future, maybe Microformats is just some interim format based on what we have exactly right now, but it will be of less, or no, value at all in the future.
@AndrÃ© LuÃs: “If we take a step back, whatâ€™s missing from the picture is for screen-readers to recognize that â€œtitleâ€ as a date. So, what if JAWS and other prominent screen readers start supporting microformats as well? And why shouldnâ€™t they? All they have to do is implement the datetime design pattern, since the markup is telling user agents that the value in the title is a date. They can read it as a date as well â€œ5th of June 2008 5pmâ€.”
Perhaps all browsers ought to localise the microformatted date, before it’s sent to JAWS to read out? Then tooltips would be presented to the reader in a familiar form too.
Alright… it’s one user and just because it comes disabled by default does not mean it’s ignorable… but that also doesn’t mean we should all forsake microformats and go back to … pure html.
I do think the community should come together around this and work out this issue. As I see it, it’s the Achilles’ Heel of the whole movement. Whenever the subject of microformats comes up, if there’s anyone interested in accessibility in the group, so does this issue.
I have no means to do research around this subject, but I’m hoping someone on the lists does… :-\
Does the class attribute have restrictions that stop you from putting the timestamp inside it?
It'd stop you having to use inappropriate elements and the title attribute:
To be held on
<span class="dtstart 1998-03-12T08:30:00-05:00">
12 March 1998 from 8:30am EST
Thanks for the link!
It's an interesting idea, and I guess it wouldn't be too hard for a parser to do that.
There have been some moves to find a more accessible way of encoding data for dates, coordinates and such like, such as:
<code><abbr class="dtstart" title="1.30pm, Monday 19 May (data: 2008-05-19T13:30+01:00)">1:30</abbr></code>
but, though this has been implemented in the "Cognition" parser, it has been mostly ignored by the unelected cabal which runs the microformat "community", and who seemingly have no interest in, or no appreciation of, accessibility issues.
That example looks a lot better to me. 🙂