This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2009/12/microformats-boon-or-bane.html
I’m gonna go with an 11 out of 10 on the stupid meter for all 3 described microformats.
First, they violate HTML standards. Sure, you can decorate your HTML however you want, but do not count on it not breaking some future change in the standard. Dumb.
Second, things like the “tag” microformat require that the URL being pointed to is formatted in a very particular way. Automation can’t do this - trying would destroy the point, and who wants to do this manually everywhere? A waste of time as best.
As for the resume format. Why? WTF? Seriously? Are people really THAT stupid? Humans will never read this crap, and a machine can’t do anything meaningfull with it. It does not standardize how resumes appear, and even if a machine was used to harvest this pile of crap, a human STILL has to read it to decide if it is at all useful. Pointless - you still have to do all the work you did before only now you have a pile of people wasting time creating additional markup that may actually break other things later on.
Talk about a blatent waste of time and data.
I would like to echo Douglas Greenshields on the whole “css classes” thing. This is the same logic that ASP.NET developers are poisoned with throughout their web development carerr.
“HURR DURR; HTML is graphical, the only REAL data is on the server; DURR”
The reason CSS elements are commonly used for microformats is:
a) they already exist (e.g. no HTML extension)
b) people already tend to name them something that describes what they are anyway (really calling the section on your HTML “address” instead of your rad cool name that nobody else cares about for your resume causes you to flip out?)
c) by using the names they do not harm existing layout
The real beauty of this is that it leverages everyone’s self interest for the benefit of everyone. Designers want to make nice looking pages using CSS. People want to make their stuff available for search. Search engines want to improve their indexes.
I fully agree that the microformat solution is poor and has a shady foundation, but I too want to reject against the following:
“We’re overloading the class attribute with two meanings”
Unfortunately, this failure to understand the DOM is more the rule than the exception. It’s quite sad actually. First we styled directly in the HTML. Then the world saw the light, and we started using CSS to seperate style from markup. Now, we are in a cross-over phase where style and markup are seperated in files, but still hard-linked, and our markup is still as poor as ever.
I’m a little confused about what those google search results have to do with… anything. What are they supposed to be illustrating?
NVM, the yellow highlighting just made the important bit hard to notice
got this discussion a while ago on SO.
Of course, I tend to agree with Jeff. It’s technically wrong to overload the css class with semantic meaning. The css class is there to bind against a representation (style) meaning, nothing more.
Very good post.
Seems like a yet another standard If it isn’t widely adopted, impleting microformat sounds like waste of time…
Right, but if Google adopts it in search results, game over: it is the standard. That’s clearly happening.
Well, it depends on the impact on SEO. If you won’t get real benefits from it, I don’t think the customers will pay for adding that feature. If web pages that use microformats get higher page ranks or get higher in search results (at least for keywords linked with microformats) lots of people will start using it. However, is it really happening?
Another use of microformats is to allow for a better integration with other applications.
I.e. right click in the browser and add the information in your address book/calendar app.
See “Tails Export” add on for FF
There are real semantic vocabularies like FOAF and DOAP that can be used/created for these kinds of things as specific instances of RDF/OWL that a that are not ambiguous in their structure or semantics. Sure they are more complicated, but that is where we really need to get to, not, as you eloquently put it: “a giant wobbly teetering tower of nasty, patched-together hacks”.
then who is gonna coordinate this standard amendments , that is the real crux from my view of point
I’ve been using Microformats for a few years; as soon as I discovered them I thought “hey these look cool, and I like making things Accessible, I’ll use them”.
Like Jeff I struggled to get the syntax right, reading this post reminds me just how fiddly and ‘just-so’ the format really is. I think the idea behind the format is a good one and trying to fit in something new on top of the current languages is a tricky problem - but I understand why they went with overloading the class. I don’t think it’s a pure solution, I would prefer to keep the class for css (though to some extent I’m already blurring that line with jQuery as it uses classes too).
Wouldn’t it be great if HTML5 had built in support for something like this, clearly defined tags with semantic meaning. Yes “header”, “footer” etc go someway to dealing with it but perhaps not far enough. HTML5 should not care about backwards compatibility and simply redefine html as it should be, leave it upto the browser to handle interpretting HTML4 / HTML5.
Just a few queries about some of your points regarding ‘overloading CSS classes’, and the danger of altering the meaning of your CSS classes away from styling … I always believed that classes within your HTML were intended to supplement the (limited) number of tags available in adding semantic meaning to your content.
The ability to use these classes as a hook within CSS are a secondary benefit, as far as the mark-up language goes, hence the (very good) practice of using class names that descibe the content, rather than the intended visual layout of the content.
Microformats, in my mind, are a way of defining a list of commonly used data types, (address, telephone etc) and the class used to describe them, so that we all sing from the same hymn sheet so to speak.
Of course, as HTML5 gets closer, and future generations of mark-up langauges after that, the use of these classes will, (and should) dwindle as we have proper tags to use instead.
Are you not doing CSS “wrong”. There shouldn’t be any styling in the HTML. Having a class named “red” is presentation and belong in CSS, not in HTML.
A developer working on CSS selects the data classes that she wants to style and styles those in the CSS code. Otherwise CSS is just a mapping between the class “red” and the CSS code “color: #FF0000”.
The proper way to do it is to structure your data according to whatever format you want (in this case, microformats) and then style as you want to in CSS. E.g. “fn org url” should be blue and underlined.
I take issue that “overloading the class attribute with two meanings” is a bad thing.
If you look at the spec (http://www.w3.org/TR/html401/struct/global.html#h-7.5.2) it states:
The class attribute has several roles in HTML:
* As a style sheet selector (when an author wishes to assign style information to a set of elements).
* For general purpose processing by user agents.
According to the spec the class attribute was designed with extensibility in mind.
The “data” attributes are for something else:
"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 attributes are not intended for use by software that is independent of the site that uses the attributes."
What would be relevant instead are RDFa or “microdata” (currently in HTML5).