I recently added microformat support to the free public CVs at careers.stackoverflow.com by popular demand.
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 recently added microformat support to the free public CVs at careers.stackoverflow.com by popular demand.
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â
No youâre not. When you add a class to a HTML element, you are supposed to give semantic meaning to the DOM. I repeat: the DOM. Next, this meaning can be used for parsing (if you use XHTML), interaction (javascript) or styling (CSS). You call a postal code box âpostalâ, not âgreyboxâ or âborderedfieldâ.
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.
http://stackoverflow.com/questions/1650401/semantic-html5-back-to-the-90s/1650465#1650465
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).