I don’t think the term “CSS classes” is correct. The class attribute in HTML is part of the HTML specification, which CSS uses. I believe the correct usage is “HTML classes.”
http://www.w3.org/TR/html401/struct/global.html#h-7.5.2
Microformats are useful. Consider this: if, on my app’s sign up page, the end user could type in their twitter username, and the app would retrieve the microformat present on their twitter homepage to autocomplete data in the form fields. That could be a nice feature.
Whoops, sorry for the double comment.
To me microformats are a very bad engineering decision, compared a custom XML micro-language. Such a language would have a set of clearly named elements, augmented, as necessary, with clearly named attributes. There’s no limitation on the number of either, so you don’t have to stuff too much information into a single text string and then parse it later; one of ideas of XML is that everything has been parsed already. Along with primary matter attributes you can have such niceties as language version, so it can develop further. And all this rich structure can easily merge with any other XML document, because XML was designed to be extensible in this way.
The only ‘advantage’ of microformats is that they will pass the W3C validator, while a custom mix won’t. And this is, I believe, the real cause why they emerged in the first place: to stay within ‘safe’ and ‘valid’ XHTML, for some reason I cannot grok in its fullness.
Sorry but if you are that concerned that someonne will come a long later and rename/reformat/remove the microformatting then should you not do what you should and comment it?
Jeff has gone about comments before and this is the perfect time to use them.
I’m sure this is entirely against the point of microformats, but could you have implemented it as an entirely new block of html. Then put this hResume block below the html that actual displays the CV, and make this block hidden using css. I’m sure this is against the point, but would this work? would it be a valid hResume? I know duplicating the data would be “bad” form but it would probably make the code cleaner for the developers. Just a thought… I’ve never implemented any microformats yet.
Nothing based on XML can possibly claim to be “Designed for humans first and machines second.”
It’s a shame that “because google does it” is considered a good development decision.
Steevo-O,
Anymore “because google does it” is the development reason!
I agree with others above. This thinking is backward. Our goal should be that HTML documents–including their class tags–denote only text (and input controls, images, etc.) with semantic meaning. We do often have to compromise. It’s sadly rarely truly practical to have any kind of pure HTML document with no regard to layout, style, or behavior; but that’s still the goal.
Then CSS and jQuery/JavaScript are each layers on top of that.
It sounds like these microformats are semantic. The HTML class attribute seems to me to be a perfectly appropriate place for such meta data. Sure, it’d be nice to have these formalized in the HTML spec itself, as a custom XML micro-language, or at the very least implemented in a way to reduce collisions.
It seems that the names that are the problem, not the placement.
As others have said, the argument that putting some sort of semantic information in the class attribute is a bad thing, doesn’t really hold water. The class attribute is an excellent application specific field to store just this kind of information. As others have said CSS is one application, but there are plenty of others. Also, in the case of conflicting styles, it is easy to set a context on the class:
.vcard .address
For example. Also, as HTML and CSS supports multiple classes, it is a tactic that one would utilize it for more complex styling. As someone who has worked with word processor inner workings, this concept is actually very powerful. You can create a set of style intersections while still keeping a semantic description (ie class=“bold-italic title-margin subject”).
As for the actual usage of microformats, it seems rather silly. It is not silly in terms of the techniques, rather the actual formats themselves. The whole vCard idea makes some sense in some applications like Google Calendar for example, but honestly, where else does this rapidly improve things? I think microformats as a technology would have been better off providing an obvious and more widely usable example what’s currently available. My guess is that microformats were a spec designed for the future rather than one that came about from real world examples.
Regarding your point of overlapping names:
I recently asked a related question, “How can I best avoid using reserved or key words in my language or framework?”
I learned Stack Overflowers are not at all sympathetic to this issue.
Erm. CSS is the presentation layer. HTML the semantic structure of a document. Class names should never reflect what the element looks like but should describe the purpose of the element. Using microformats in the class attribute describes the data - its semantics and css can be used to style these class attributed elements. Microformats make perfect sense to me and I always felt that they added meaning to elements, not “overloading CSS classes”.
If I hired a UI developer who chose to go with a new naming convention for css selectors or php class or function names, for that matter, without discussing it with his team, that would be a failing on my part. Also, if i was hiring for a UI dev position, id expect the hired developer to know what Microformats are.
Microformats may be tricky, but what are the alternatives?
I’m not quite enough of a cynic to support #3, so that leaves microformats. And as hacks, go, it’s not too shabby.
+1 to everyone pointing out that there is no such thing as “CSS classes”. There is an HTML class attribute, intended to carry additional semantic metadata about the contents of a tag, and also incidentally available as one of several places for stylesheets to hook in. Microformats use the class attribute exactly the way it should be used.
you forget one thing in your self-advertising. Microformats are not for users. Firms want Word. Users use it and can format as they wish (and not those bllshit like spaces at end f aline for formating).
Eric larsen says:
“My guess is that microformats were a spec designed for the future rather than one that came about from real world examples”
Yeah, I’m sure that’s right. Nevertheless I’m sure microformats have a use. There was at attempt to make them useful a few years ago with the development of Live Clipboard: http://www.liveclipboard.org/ . Unfortunately that seems to have died a quiet death!
-Jamie
Jeff, microformats evolved out of a desire to semantically express what people were already doing and publishing. The first microformat, XFN, uses the ‘rel’ attribute because it makes the most semantic sense. (The identity microformat is an offshoot of XFN.) For similar reasons, the tag microformat uses ‘rel’. Both are fortunate that an HTML attribute exists that models what they are expressing. As is the license microformat, which uses ‘rel=“license”’.
But for most things that people want to semantically express—geographic coordinates, contact information, resumes, calendars, recipes, and so on—there are no HTML4 or XHTML structures to accommodate them. The only path open is the ‘class’ attribute, which is technically quite appropriate (as others have pointed out) but a pretty small container for all the things that might be stuffed into it.
Had there been a way to create and use arbitrary attributes, that’s what would have been done. As you noticed, HTML 5 adds the ability to create arbitrary data-* attributes. There’s a reason for that. As HTML 5 usage spreads, I would expect most microformats to be revised to use data-* instead of ‘class’. Before anyone asks why that wasn’t done in the first place, microformats are by now a few years old, and predate HTML 5 by at least three. As microformats were being created, there was nowhere else to go.
I have to admit that the end of the post made me smile, because you put your finger squarely on one of the most powerful things about microformats: they’re so easy to implement. That is completely by design, and it helps explain why they’re catching on, warts and all—just like the web itself did back in the day.
ditto everyone claiming you have a wrong perception of class.
Class should describe the content. It’s just convenient that in CSS we can easily use class selectors to apply styles.
But the point of the class attribute, is to to describe the content semantically. If you took away the stylesheets, the class names should still mean something.
Microformats are the internets eternal buzzword. Semantic html was supposed to be the bees knees and why 4-5 years ago everybody stopped abusing html.
Then nothing happened. Nobody parsed html in a cool way, big companies created web apis instead, and everybody forgot about the promises they microformats and the semantic web was supposed to deliver.
Card image…
Just punch some holes…
No seriously, what ever happended to ‘getting away from the card image’?
Back in prehistoric times (when I first got into this) I had decks of punch cards with my programs and data in them. They worked ok but the machines were very finicky about trivial things like, sequence, little pieces of dust or paper,extra holes, bendind…
I thought the entire purpose of modern data methodologies was to get as close to free form binary data as possible. I know, I know, this is an impossibility but at least we should be striving forwards and not backwards.
There has to be some reasoning behind this, like being able to walk the page looking for relevance…
It just seems like a step backwards to me…