Markdown and the hCal microformat
mike at cs.ucsd.edu
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</
> <span class="location">Room 200, Bldg 3</span>
> <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>
> 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
> And while it probably is different enough from links in the
> parser's eye, it probably has enough similarities to confuse a
> 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