Community Group for Markdown Standardization
michel.fortin at michelf.ca
Wed Nov 21 12:04:34 EST 2012
Le 2012-11-20 à 20:36, marbux <marbux at gmail.com> a écrit :
> "Every MD implementation would have to have two behaviours, set either
> by a command line flag, a configuration file, or a preference if used
> with a GUI. One behaviour would be the individual behavior so that
> the followers of that implementation wouldn't be left in the lurch.
> One would be the standard behavior."
> I think the behavioral switch could be handled automatically if the
> standardized version has its its own doctype declaration and profile
> header. If the doc has the doctype declaration, then process the doc
> as the standardized version of markdown; if not, then apply the
> implementation's unique default processing.
If your idea of an improved Markdown is one that starts with a doctype, I'm afraid it won't get very far (with users and implementers alike).
> Bridging the A11Y gap is in my view a major
> incentive for MD implementers to participate in the working group and
> to implement its deliverables. This is a legal requirement for web
> sites at least in the U.S. and E.U. Although enforcement has been lax
> so far, there is no guarantee that enforcement won't be ramped up
I think you're mistaken about exactly who are the implementers. Most of us implemented Markdown for our own needs, then shared the code so other could use it. Then did some maintenance on the code in our spare time (at least some did). If any of us had this legal requirement to satisfy, or too many users nagging for this, it'd already been done. Changing the output is a piece of cake by the way.
So feel free to suggest improvements to the output. But I doubt very much it'll have any effect beyond changing the output for some willing implementers.
The reason most people wants a spec is to help various implementations interpret Markdown text the same way, and that is the hard problem. That's the problem that would require long discussions -- if not negotiations -- especially because it is likely to require near complete reimplementation from many of us (because various implementations have very dissimilar parsing models currently).
I, personally, don't have the time for this. As it is now, I barely have the time to do maintenance work on PHP Markdown and PHP Markdown Extra. PHP Markdown and its Extra counterpart probably have thousands of users, if not more (I have no way to measure that), but my spare time doesn't scale with the number of users and I have plenty of more interesting things to do in my spare time.
>> The exception to that is support for the one feature that is likely to be added which has no direct support in HTML, precisely because of that lack of direct expressibility in HTML, namely footnotes. (Or has HTML 5 provided a solution here (and one that isn’t still evolving)?) "
> Kinda'/Sorta'. HTML 5 has the "aside" element that was originally
> stuck in with footnotes in mind.
> <http://dev.w3.org/html5/spec/single-page.html#the-aside-element>. But
> it's really just a container that can be positioned on the page with
> CSS. No footnote/endnote-specific markup. (I'll omit my long rant
> about browser developers and their mindset when it comes to HTML spec
> footnote proposals. Let it suffice to observe that repurposing of
> content never enters their minds when the topic of footnotes comes
Some things of interest:
Footnotes were discussed at length in 2008 at the WHATWG.
I started to write a detailed spec in 2008 for a new Markdown Extra parsing algorithm and document model (which includes a Markdown subset). Despite being fun to work on, I stopped because it was too time-consuming.
Pretty much at the same time, I made Babelmark for comparing various Markdown implementations. Ian Hickson wrote a similar tool to see how browsers were parsing HTML snippets to help build the parsing spec for HTML. I figured it'd help to have something similar for Markdown.
John MacFarlane rewrote it as Babelmark 2 a few months ago, with more up-to-date versions of the implementations. It's really great.
- - -
If I had to "fix" Markdown today, I'd radically change to a cheap approach. I'd take the few worse cases from the Babelmark 2 FAQ, try to come up with a "right" way to parse these, put them in a test suite and try to convince other implementations conform to that test suite. Even that would probably be a hard sell to me, and probably others. I'm pretty picky about what's "right" and "wrong" in Markdown.
michel.fortin at michelf.ca
More information about the Markdown-Discuss