xMarkdown implementation

Mon Mar 29 19:19:19 EST 2004

John Gruber wrote:

>Bob, this is just terrific. Wonderful stuff. I simply don't have
>time at the moment to really dig in to what you've done, but at
>first glance, I'm both impressed and delighted.
>  
>

Cool, I'm glad you like it! I have to say, I'm equally impressed with 
the work done on Markdown (both of them) so far.

>But even that falls short of addressing the issue, because what
>happens when you want to include an empty element tag, e.g., a br
>tag with a custom class. One might use either of:
>
>    <br class='foo'>
>    
>    <br class='foo />
>
>One is HTML 4, the other XHTML. Markdown puts the responsibility for
>doing this correctly on the writer's shoulders.
>  
>

Yep, exactly, and I don't think you can readily get around it - when 
talking of fragments, it's difficult to talk about "HTML validity" 
anyway, because it ain't ever going to be - you don't have the <html>, 
<head>, etc.. so you're starting to talk about a subset of rules, in 
which case it's difficult do mechanically and potentially not complete 
anyway. Or, you could look at the complete document as a whole, but 
that's a lot of trouble.

Certainly the "Markdown doesn't specify an HTML version" comment wasn't 
made as a criticism, more a kind of "this is the nature of the beast" - 
this aspect, processing raw HTML, is the area I think xMarkdown is 
always going to be at a disadvantage: turning tag soup into XHTML (which 
xMarkdown has to in order to output it, but Markdown doesn't) isn't 
terribly easy or even necessarily possible.

>>I hope people find a separate codebase kind of interesting, anyway, not 
>>least from a pathalogical point of view ;)
>>    
>>
>
>I certainly do. I hope you're willing to keep your implementation up
>to date with the handful of additions I have planned going forward.
>  
>

Yeah, it's basically intended as a Markdown parser, not a Markdown-alike 
parser. The additions discussed so far seem pretty sensible, I think the 
ability to fall back to HTML means that new syntax has to be a fairly 
big win to be useful, which is a good yardstick when adding/making 
changes. So, I do currently plan on implementing them (certainly up to 
1.0). Some of them are actually already implemented, at least partially ;)

There are a couple of extra features in xMarkdown, most of which are 
curios I implemented for my specific needs - xMarkdown is very much 
"tool of Bob" at this stage. The reason I implemented it was because of 
running a strict xhtml1.1 blog; if the post is malformatted I'm 
immediately in trouble, since my edit buttons (etc.) are all on that 
same page with the post on it - if I can't see the page the whole tower 
of cards comes crashing down since I cannot fix the page. It's a lovely 
catch-22. Hence requiring something which was certain to output at least 
valid XML.

To an extent, I'm less interested in the syntax per se than the 
possibilities of the syntax - one of the plans I allude to is fronting 
xMarkdown to CGI::KWiki. A while ago I posted some patches to improve 
the XHTML-ness of Kwiki, which were useful but I realised were only part 
of the problem. Much of the problem is the syntax and the way it's dealt 
with - I think a fair description would be that the output is 
workman-like. Replacing the standard Wiki processor immediately makes 
Kwiki standards-friendly, and also opens the way for some interesting 
page transformation stuff (for example, being able to write <a 
href="WikiPage"> is quite useful - you want to wrap something like an 
image, but you don't want to extend your wiki syntax to cover this 
corner case because 98% of your links are just plain text, and you 
certainly don't want to hard-code the link itself)

>Thanks. More comments to come after I get a chance to do more than
>kick the tires.
>  
>

Much appreciated :)

-- bob.