Markdown and the hCal microformat

Michael McCracken mike at
Mon Aug 7 17:35:15 EDT 2006

On Aug 5, 2006, at 8:47 PM, Michel Fortin wrote:

> Le 4 août 2006 à 18:43, Michael McCracken a écrit :


>> On Aug 3, 2006, at 12:53 PM, Michel Fortin wrote:


>>> I agree with this. Calendars can be written in a lot of different

>>> ways, and the output expected will vary depending on the

>>> application. Keeping this separate as an extension to Markdown

>>> seems the best.


>> Did you mean calendars can be marked up in different ways in HTML,

>> or that people will want to write different markdown-style syntax

>> for calendars?


> Both. In my view, almost any Markdown-style for calendars is going

> to have limitations which will prevent it to suit some peoples

> needs. And such limitations are going to be reflected by the lack

> of flexibility in the output.


> If I'm not mistaken, there are many ways you could format you

> calendar events which are all valid hCalendars. For instance, could

> you not put all your event data in a table of this form:


> | Event | Date | Location

> | -------------- | -------------- | ----------------

> | Big meeting | 23rd June 2002 | Room 200, Bldg 3

> | Bigger meeting | 24rd June 2002 | Room 200, Bldg 3


> ? Sure you could, with the revealing classes and `<abbr>` elements

> put at the right places.


> I think the big problem about integration of microformats like

> hCalendar (or hCard) is that they are a purely semantic layer

> applied over the structural markup. It doesn't mean it cannot or

> shouldn't be part of Markdown, but if it does, it probably should

> acknowledge that fact and be flexible enough so that authors can

> write calendar events the way they want.

OK, I agree here - I was hoping to find a reasonable syntax that
would work for the way many events are written, but maybe there are
just too many different ways to do it.

So this now seems to be a good example for the need for extensible
Markdown syntax, which I'd certainly support, but is more than I
wanted to bite off. :)

>> I was hoping to start a discussion on what the 'markdown way' to

>> write calendar entries should be.

>> I tried to start from what I'd seen in emails, but I was hoping

>> for some feedback about the syntax I came up with.


> Ok. Let me review your proposition, which would transform this:


> (23rd June 2002)[Big Meeting @ Room 200, Bldg 3]

> (10am-2pm)[World Cup game]


> into this:


> <div class="vcalendar"><span class="vevent">

> <span class="summary">Big Meeting </span>

> <abbr class="dtstart" title="23rd June 2002">23rd June 2002</

> abbr></span>

> <span class="location">Room 200, Bldg 3</span>

> </div>


> <div class="vcalendar"><span class="vevent">

> <span class="summary">World Cup game</span>

> <abbr class="dtstart" title="10am">10am</abbr></span>

> - <abbr class="dtend" title="2pm">2pm</abbr></span>

> </div>


> Beside the inflexibility of the output, what I don't like is that a

> ()[] syntax looks like a span-level syntax, while it produce `<div>`s.

It didn't have to produce divs. That wasn't really a conscious
decision, honestly.

> And while it probably is different enough from links in the

> parser's eye, it probably has enough similarities to confuse a

> beginner.

fair enough.

> Also, your repeated "vcalendar" `<div>`s serve no purpose. From the

> hCalendar microformat page:


>> Authors may explicitly use elements with class="vcalendar" to wrap

>> sets of vevents that all belong to the same calendar


> but you're creating a different calendar for each event!

Yes, this is a good point in that it isn't clear where to start and
stop a vcalendar without adding more markup.

>>> Yes, PHP Markdown, the object oriented version I announced a

>>> little while ago, is better suited for extension than John's Perl

>>> Markdown. But there is no "intelligent" way to add a function in

>>> the middle of the processing chain other than by replacing the

>>> caller function, which makes any extension rather inelegant (but

>>> still better than before). Improving PHP Markdown's extension

>>> capabilities is on my todo list.


>> As far as extension, I think there will probably be a small set of

>> microformats which could reasonably be included in the core

>> Markdown syntax (assuming that the Markdown community is

>> interested in microformats). Specifically, I mean the hCard

>> contact info and hCal calendar entries.

>> If it's just two formats, perhaps extension is unnecessary?

>> (Especially considering that extension support is not present in

>> current Markdown versions?)


> The idea of an extension is that you can build the one *you* need,

> and share it with other people who needs it if you want. But it

> can't get in the way (or the processing time) of those who do not

> have a need for it, or those who aren't satisfied with your version

> of the syntax and its corresponding output.

Alright, I'll keep an eye out for a good extension mechanism, then.
I'll be an early customer, I guess.

> I think that until we have a clean way of integrating hCalendar or

> hCard into various HTML structures from within markdown, it should

> probably remain separate.


More information about the Markdown-Discuss mailing list