“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.”
That is so wrong I almost wonder if it’s sarcasm. The markup in a HTML document is supposed to convey semantic meaning, not stylistic meaning. A class named “red” is a bad use of the class attribute, we all know this. The class attribute is supposed to tell you what the data is not how it should look.
Semantic markup! Semantic markup! How many times have we heard that phrase? What is semantic about a class that conveys style meaning? Nothing!
You’ve got it completely backwards Atwood. Edit this post now before you delude more poor souls into your foolish “Everything in HTML is semantic, except the class attribute” line of thought.
I’d echo Ben’s comments, class is intended for “For general purpose processing by user agents”, as well as being a hook for styles (or JavaScript). With microformats, someone with a browser pluggin can add events straight to their calendar, or Yahoo might index all the CVs better.
However, I don’t think there would be much support for loading the HTML5 (or 6) spec with lots of specific scenarios for this type of markup, that’s what the generic elements (like class and itemprop) are for.
However, microformats could greatly simplify the specs for HTML5.
We’re overloading the class attribute with two meanings
It’s pretty common to use the class attribute to allow, say, JavaScript to identify a set of elements. It’s the only place in HTML where authors can add their own semantics.
Although we mostly do this for styling purposes, I don’t think there’s anything inherently wrong with using it for other purposes.
Would also have to agree that the MF solution is a little wobbly, but at the moment is the best option available.
Also have a need to chime in on semantic vs presentational class names.
It makes me cringe when I read bedroom posts by self proclaimed css experts [not referring to Eric M and others that really are experts] “don’t ever ever use tables, google used a table and they are wrong/lazy/stupid(orly?),…”, who then champion the use of presentational class names like “col1 bold red double-space” and call it a css framework.
How is that any different to the bad old days of wrapping it all in font tags? Different mechanism, same crap.
Personally, class=“postal-code”, despite the foibles of MF, seems much more semantically correct to me. Hell, ignore MF if you want to, but call it what it is, not what it looks like, wasn’t that the point in the first place?
Heh, if you have an issue with microformats, wait till you read about The Semantic Web, RDF, ontologies etc.
But it is misleading to call it a “CSS class”. The class attribute in div and span is supposed to indicate what the content means, so that some application can reference it and do something appropriate with it. CSS is just one of those applications that happens to take care of the presentation.
99% of the time though, its best to just have the human readable HTML document web, and the machine readable XML/Web Service web, but for those times where you really need machine readable documents (I mean, documents are a human readable abstraction of information after all, if you need them to be machine readable, you are using the wrong abstraction), microformats are an ok solution. The problem domain isn’t as large as the Semantic Web and microformat people think though.
Whilst I would echo peoples comments that class attributes are to have semantic meaning rather than stylistic, I think some of Jeffs points still stand.
The invisibility of the format, for instance. You have to tell people exactly which parts are the microformat, or they have to know, so they know which bits not to touch. Whether your classes are semantic or not there is still the risk of people deciding to re-factor for naming consistency, or removing “unused” or newly “redundant” classes etc. Especially with the more complex microformats.
Whilst classes may have been designed for extensibility it still seems brittle, and there are still problems with using classes which aren’t used directly by the project like css or jQuery does, but has some invisible use by the browser.
I’m hearing your followers argue for the class attribute “overload” and I’m also hearing your concern about the overload. My sentiments tend to match yours when it comes to microformats: For situations where they are easily implemented, great! Use them. But (in general) using them for anything more than a simple telephone number, it becomes more difficult just to get the right syntax than it does to just ignore them. For something that is supposed to be simple, theya re incredible difficult to use properly.
Definitely agree with you on this one. The scariest thing is there is no indication that you are using a micro-format when you use one. I really don’t see anyway around it or to enforce it with the technology stack we have. You are also right about Google. If they adopt it, you can’t really fight that.
I really think maybe they should have prefixed the class names with something like mf-. Maybe class=“mf-street-address”. This would have greatly reduced the chance of problems with existing code and made it much less ambiguous when reading your code.
Definitely agree with the sentiment, Jeff. Overloading aspects of the view (HTML, CSS) to denote content seems shoddy and hackish. This sort of metadata should be separate, and in my mind ought to be ideally handled via some form of content negotiation. Unfortunately, the path most likely to succeed is the path of least resistance, and that path is going to be extra markup tacked on to existing HTML. This makes me almost yearn for meta tags. Almost.
Hi Jeff,
I’m the guy that originally made the request for you to implement hResume so thank you for doing it - and so quickly as well.
On the subject of whether they should be used or not … my request came from a desire to see more structured data on the web. I don’t particularly care much for which implementation is used - I suggested hResume simply because I knew it existed. I hear lots about RDF/RDFa and perhaps that is the future but in the meantime using microformats is no bad thing.
I interpreted your post here as “microformats are a pain but the pay-off is worth it” and if so I would wholeheartedly agree with that! Hopefully we’ll get some big oak trees from little acorns like your implementation here.
We’re overloading the class attribute with two meanings
Actually, as other people have mentioned we are following the Html spec.
The microformat css class names may overlap with existing css classes
Awesome. I guess you and the microformat designers think alike. No work to do. Oh, you have a problem because you assigned the class “postal-code” to something that was not a postal code. Oops.
3.There’s no visual indication whatsoever that any given css class is a microformat
It’s class name. You seriously want to force namespacing on every microformat because you don’t think it is reasonable to get everyone to agree to call a spade a spade. How about you prefix all of your class names with “my-” and everything will be honky dory?
Anyway, I’m sure some enterprising sole will write a plugin to syntax highlight standardized class names.
The spec is incredibly ambiguous
Probably. Most young specs are. As it becomes more popular I would expect the wrinkles to get ironed out. Having said that, your opinion on the spec is a bit dubious considering you haven’t read the html spec well enough to understand what the class tag can be used for. And you have been doing html for how long?
It doesn’t handle unstructured data well
You can’t blame this in the hCard format. If you ask the user to enter an address freeform, don’t expect to be able to expose the data in a structured way.
Regarding your points 1 and 2, can’t you just give the resume elements multiple class assignments? Yes, browsers =IE6 have issues with it (http://www.quirksmode.org/css/multipleclasses.html), but since your microformat isn’t actually going to be assigning style, it should work.
Do the tools consuming microformats not support multiple classes on a single element?
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.”
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.