bob at wolfwall.com
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
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 :)
More information about the Markdown-discuss