sgbotsford at gmail.com
Wed Mar 17 10:55:21 EDT 2010
Getting agreement on the corner tests should be easy. Most of the time the
corner test is odd enough that it never came up in a production environment,
and so deciding one way or another is less likely to break something.
Having an MD compliance test may be *the* way to go.
MD has forked. 20 times or so. No way we are going to stuff that many
worms back into the can.
An MD standard, and such things as this list can rationalize the situation.
The end result is that the testing group IS MD. Everything else is
implementations of MD.
So it's called Markdown Standards Group, -- MSG for short.
One possibilitiy is that we end up with a test similar to the ACID browser
test that checks compliance with W3C standards. You end up with a score.
Another possibility is that you have a web page where each implementation's
differences from the standard are shown.
If the 'market penetration' of MD can be determined for each flavour, then
any feature that is present in X% of the market becomes a 'core' feature.
The best way to determine market penetration is to encourage developers to
set up a list (how 'bouth this one...' and use a vote. Implementors would
be encouraged to put contact info for thie list in their source code and
For a given feature and implementation:
* It's implemented as per core standard.
* It's implemented with quirks. Quirks can be edge behaviour with special
cases, html code that presents itself the same visually, but is different
behind the scenes. E.g. MMD ignores blocks encased in <div> as per
standard, but wraps <DIV> in <p> tags and processes everything inside
normally. I like this quirk, but I could do without the <p> tags.
* Normal behaviour is different, but can be brought to standard with flags
or a configuration file This allows variant implementations to get accepted
status without breaking their established base.
* It doesn't meet the standard at all.
If you want to be true to JG's heritage, he is asked to rule on any specific
corner case of the original specification. He's also asked to put a link to
the MSG web site on his MD page. This gives him a say in what happens, and
is a graceful way for him to pass down his heritage without spending a lot
of time involved with it.
I think also that any web site put up should acknowledge JG, and have a link
back to Daring Fireball.
I think it wise to change the name, but it should be clearly derivative.
* Markdown 2
* Markdown II
* Markdown NG
Sherwood of Sherwood's Forests
Sherwood's Forests -- http://Sherwoods-Forests.com
50042 Range Rd 31
Warburg, Alberta T0C 2T0
On Wed, Mar 17, 2010 at 4:33 AM, yy <yiyu.jgl at gmail.com> wrote:
> 2010/3/17 david parsons <orc at pell.chi.il.us>:
> > There are markdown implementations in a dozen languages. I am
> > unsure about how a common tool can be made here.
> What I would really like to see is a standard test suite, with a given
> input and the expected output, which we can test against the different
> implementations. Then, we would only have to agree on a "core" set of
> tests that every implementation has to pass to be considered "markdown
> compatible" and we could easily add tests for non-standard features.
> The difficult part is to decide if the most strange corner cases are
> implementation dependent, or how they must be handled (since I expect
> some differences between current implementations). Mdtest is probably
> the best starting point for such a task.
> - yy.
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Markdown-Discuss