Markdown and the hCal microformat

[Michael McCracken]

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.


Thanks,
-mike