That example looks a lot better to me.

<abbr class="dtstart" title="1.30pm, Monday 19 May (data: 2008-05-19T13:30+01:00)">1:30</abbr>

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.

Thanks for the link!

Ash,

It’s an interesting idea, and I guess it wouldn’t be too hard for a parser to do that.

It’d stop you having to use inappropriate elements and the title attribute:

<p>
To be held on
<span class="dtstart 1998-03-12T08:30:00-05:00">
12 March 1998 from 8:30am EST
</span>
</p>


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… :-\

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.

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 title attribute: 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.

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?).

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?

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.

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.

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 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.

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, 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.

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.