mofo syne | 19 Sep 19:41 2014


A concept you might be interested.

![ cat ]( cat.png 100x100 ){ #id .catClass }

Is another way of saying:

!default[ cat ]( cat.png ){ #id .catClass width=100px height=100px}

which is just an extention that detects ".png" so that its more like:

!embedImage[ cat ]( cat.png ){ #id .catClass width=100px height=100px}

before outputting into html.


!extentionName[ content ]( arguments ){ #id .Class arg1="" arg2="" argEtc="" }

!!!extentionName[ summary content ]( arguments ){ #id .Class arg1=""
arg2="" argEtc="" }
     .... content ...


This demarcation of extension provides interesting opportunities for
plug and play extensions, while keeping the syntax as simple as

(Continue reading)

Alan Hogan | 17 Sep 23:46 2014

Markdown within block-level elements

I just wanted to share a few short observations regarding Markdown within block-level elements, which I
(and the Common Mark project) wish to be enabled by default.

1. I believe this to be a very desirable feature for writing Web content. (See item #6 for specific
motivation. Generally and intuitively, I expect everything in my markdown document to be subject to
Markdownification, with the exception of indented, fenced, or back tick-delimited code and content
within (not between!) HTML tags. )

2. If your parser/converter does allow this, *please* make sure it is HTML5-aware. There should not be this
much difference between a <div> and a <header>.  Just look at how many implementations consider <header>
to be plain text, wrapping it in paragraph tags!


3. Michel Fortin came up with a clever solution to allow this at authors’ discretion way back when, but it
is not popular, and most other flavors ignore the markdown=“1” flag altogether. It is usually echoed
into rendered HTML by other flavors. It is One More Thing for an author to memorize, so I don’t love the
writing experience with it, either. I would like to see Markdown within block-level elements to be the default.


4. This won’t be a surprise to anyone, but the differences between flavors here is causing me real
problems as an author. I am currently writing in iA Writer, previewing with Marked, managing changes with
GitHub, and publishing with PHP Markdown Extra. Naturally, these all give different results,
decreasing (a) my confidence as an author and (b) the utility of Markdown, since I am forced to write more
raw HTML to get consistent and desirable output.

5. Look for Common Mark, a.k.a. “stdmd 0.1”, in Babelmark.
(Continue reading)


big companies and bloated code

so i'm finishing up my latest example
of a working light-markup system, and
it's running under 45k at the moment.

i thought i'd include "embedding" in it;
you know, the typical stuff from youtube,
and twitter, vimeo, vine, instagram, etc.

my word.

embedding from these big companies
involves some extremely bloated code,
ranging anywhere from 150k up to 950k
for every single one of 'em. i kid you not.

excuse me?

after i've worked so hard to cut my code
to the bone to make it as small as i can?

i even did the grunt work of converting to
vanilla javascript, so i could drop jquery.

and guess what?

an instagram embed downloads jquery!
it's version 1.7.2, so it "only" weighs 95k,
but by itself it's twice the size of my code.

(an instagram embed is 750k, which does
(Continue reading)

choptuik | 16 Sep 18:43 2014

Where to report possible bugs ...


I'm new to both this list and the use of markdown, so would like to know 
whether this is an appropriate place to report possible bugs.  If it isn't I 
would appreciate if someone could point me in the right direction.


Matt Choptuik

Matthew W. Choptuik|Phys & Astro, UBC|Hennings 403|6224 Agricultural Road
Vancouver BC, V6T 1Z1, Canada|Voice: (604) 822-2412|Fax: (604) 822-5324
choptuik <at>|
Andrei Fangli | 14 Sep 12:34 2014

Re: Flexible Markdown Parser

Hello again,

I’m happy to announce that I have a working parser fully based on regex and a default implementation for Markdown based on Gruber’s Markdown 1.0.1 (Dec 2004) specification. The only thing I could not figure out is the blank line between list items to generate a paragraph in the list item instead of plain text (that is very ambiguous to me and sounds a bit odd) and instead I decided that all list items cannot contain plain text (a very simple approach, I know).

Critics and comments are welcomed.

PS: can someone point me to some test suites you use? I would like more test cases (the ones I wrote are really rudimentary). Also big documents for performance testing would be nice.

Andrei Fangli

From: Andrei Fangli
Sent: ‎Saturday‎, ‎16‎ ‎August‎ ‎2014 ‎17‎:‎34
To: markdown-discuss <at>

I'm new around here this being my first post (if I did posted in a wrong meaner please point it out).
Since you guys are working on Markdown syntax & parsers I thought I should butt in and show off with a little piece of work that I have been working on.
Since I followed the interview with John Gruber and he stated that he wouldn't want to standardize Markdown and would rather keep the syntax description ambiguous so flavors of the language may emerge to suit the needs of the one(s) using Markdown. I realized that a parser with fixed syntax would not encourage these "flavors" at all. Nor encourage people to use it much (since my interpretation of Markdown is not universal). With that in mind I shifted from defining a rather "static" parser to a more flexible one.
The implementation (in Perl) offered by John Gruber relies heavily on regex which gave me an idea. I'm a C# developer therefore what I am working on targets .NET Framework and the idea that I got was to make parser that relies mostly on the object model of Regex offered by .NET. The current implementation is rather a prototype for a greater more powerful parser.
Now to make more sense of what I am talking about. I wrote the implementation of the parser in an abstract class delegating to subclasses what factories for node creation to use (Factory Method that returns a list of Strategies where the Strategy is object creation). There are two types of nodes: leaf and composite thus there are two Strategy interfaces.
The ILeafNodeFactory has a Pattern (Regex), a Name (to use when referencing factories from a composite one and a Create method which, obviously, creates the node given a regex Match).
The ICompositeNodeFactory has the same stuff as ILeafNodeFactory only that the Create method takes an extra parameter (a list of child nodes) and for a composite node factory you need to specify what factories are applicable to obtain child nodes (both leaf and composite work).
When you want your specific "flavor" of Markdown you simply subclass the MarkdownParser and implement the abstract methods. This means providing a list of ILeafNodeFactory, a list of ICompositeNodeFactory and the name of the factory to apply for the root node. For each node factory you need to provide a unique name and a pattern which identifies the sequence of text representing the node. For composite node factories you also need to provide a list of factory names to know what node factories to use when trying to identify a child node text sequence.
The factories are tested in the base class. E.g.: you reference a factory that does not exist, exception is thrown. Or your composite factory has MarkdownTextNode as children and in the applicable child node factories say that a factory which returns a MarkdownNode (base class of MarkdownTextNode) then an exception is thrown because there is no implicit conversion from MarkdownNode to MarkdownTextNode.
All these validations are done in the base class constructor (MarkdownParser) meaning that if you want to test your specification you only need to create an instance of it and see if it throws any exceptions.
Sadly I haven't got yet to properly testing the parser much (just a dummy test with 2 factories) or make a default implementation for the rules specified on John Gruber's site but I am looking forward to it. The project source code is hosted on BItBucket: <>.
I hope I wasn't too techy or lacky in details. Constructive comments and critics are welcomed! Thanks in advance. :)
Markdown-Discuss mailing list
Markdown-Discuss <at>
Markdown-Discuss mailing list
Markdown-Discuss <at>

wysiwyg and light-markup are oil and water

there is a lot of surface appeal to a system
which combines wysiwyg and light-markup.

and one can do a few simple combinations.

but before long, and certainly once you try
to tackle some more-complicated features,
you find yourself torn by an inherent conflict.

starkly put, there is a _difference_ between
what you put in, and what you get out, and
the question is which one you want to "see".

by definition, wysiwyg pictures the "output".

but an inability to "see" your input means it
can become very difficult to edit that input.

the inclination, upon that realization, is to
attempt to show "enough" of the input that
it becomes possible to do your editing, but
that just turns the wysiwyg into cruel illusion.

i'm not gonna say that it's "impossible", but
i will advise anyone who is tempted to try it
to carefully map everything you need to do
before you even start to think about coding.

if you want to take on the hardest thing first,
figure out how to successfully allow a paste
from an arbitrary ms-word file...  good luck...


p.s. even if you solve that fundamental gap,
you will also discover that "wysiwyg" carries
excess baggage, in that some people think
it entails one thing, and other people another,
so you're never gonna make everyone happy.

p.p.s.  all this also applies to contenteditable,
in case anybody is mulling that as a solution.

the basic gruber markdown basics


### an adaption from text by John Gruber



A paragraph is simply one or more consecutive lines of text,
separated by one or more blank lines.

Normal paragraphs should not be indented with spaces or tabs.

Now is the time for all good men to come to
the aid of their country. This is just a
regular paragraph.

The quick brown fox jumped over the lazy
dog's back.


Markdown offers two styles of headers: setext and atx.

Setext-style headers for `<h1>` and `<h2>` are created by
"underlining" with equal signs (=) and hyphens (-), respectively.

A First Level Header

A Second Level Header

To create an atx-style header, you put 1-6 hash marks (#)
at the beginning of the line -- the number of hashes
equals the resulting HTML header level.

# Header 1
## Header 2
### Header 3
#### Header 4
##### Header 5
###### Header 6

so much for headers.


Blockquotes are indicated using email-style angle brackets.

> This is a blockquote.


Markdown uses asterisks and underscores to indicate spans of emphasis.

Some of these words *are emphasized.*

Some of these words _are emphasized also._

Use two asterisks for **strong emphasis.**

Or, if you prefer, __use two underscores instead.__


Unordered (bulleted) lists use asterisks, pluses, and hyphens (*, +, 
and -)
as list markers. These three markers are interchangable.

* Candy1
* Gum1
* Booze1

+ Candy2
+ Gum2
+ Booze2

- Candy3
- Gum3
- Booze3

* Candy4
+ Gum4
- Booze4


* Candy5
* Gum5
* Booze5


+ Candy6
+ Gum6
+ Booze6


- Candy7
- Gum7
- Booze7


* Candy8
+ Gum8
- Booze8

Ordered (numbered) lists use numbers followed by periods as list 

1. Red1
2. Green1
3. Blue1

1. Red2
1. Green2
1. Blue2

9. Red3
9. Green3
9. Blue3


1. Red4
2. Green4
3. Blue4

1. Red5
1. Green5
1. Blue5

9. Red6
9. Green6
9. Blue6


1. Red7
2. Green7
3. Blue7


1. Red8
1. Green8
1. Blue8


9. Red9
9. Green9
9. Blue9

If you put blank lines between items,
you'll get `<p>` tags for the list item text.
You can create multi-paragraph list items
by indenting the paragraphs by 4 spaces or 1 tab:

* A list item.

    With multiple paragraphs.

* Another item in the list.


Markdown supports two styles for creating links: inline and reference.
With both, use square brackets to delimit the text to turn into a link.

Inline-style links use parentheses immediately after the link text:

This is an [example link](

Optionally, you may include a title attribute in the parentheses:

This is an [example link]( "With a Title").

Reference-style links allow you to refer to your links by names,
which you define elsewhere in your document:

I get more traffic from [Google][1] than from [Yahoo][2] or [MSN][3].

[1]: "Google"

[2]: "Yahoo Search"

[3]: "MSN Search"

The title attribute is optional. Link names may contain
letters, numbers, and spaces, but are not case sensitive:

I start my morning with a cup of coffee and
[The New York Times][NY Times].

[ny times]:


Image syntax is very much like link syntax.


![alt text]( "optional 


![alt text][id]

[id]: "optional title"


In a regular paragraph, you can create code span by wrapping text
in `backtick` quotes. Any ampersands (&) and angle brackets (< or >)
will automatically be translated into HTML entities. This makes it easy
to use Markdown to write about HTML example code:

I wish SmartyPants used named entities like `&mdash;`
instead of decimal-encoded entites like `&#8212;`.

<p>I wish SmartyPants used named entities like
<code>&amp;mdash;</code> instead of decimal-encoded
entites like <code>&amp;#8212;</code>.</p>

To specify an entire block of pre-formatted code,
indent every line of the block by 4 spaces or 1 tab.
Just like with code spans, &, <, and > characters
will be escaped automatically.

    To specify an entire block of pre-formatted code,
    indent every line of the block by 4 spaces or 1 tab.
    Just like with code spans, &, <, and > characters
    will be escaped automatically.

# for use in doing first-line basic testing of markdown systems
Michael | 11 Sep 21:17 2014

Free Markdown WYSIWYG editor

Hello folks,

I just wanted to share a pet project of mine:

Marko Editor, a real WYSIWYG Markdown editor.

I know that a desktop WYSIWYG editor is counter intuitive to the original Markdown goals (at least as far as I understand them) but please let me explain my reasoning:

* Although Markdown has an intuitive markup, I guess that for many ordinary people (no (web) developers) even this is too much.
* With all the current privacy issues in the net I wanted a local application. (I know one can use JS locally, too)
* Markdown focusses on content creation (in contrast to layout) and that is my goal, too.
* Markdown files are very versatile:
    * Builtin fallback to text (compared to common rich text formats)
    * Good diff and merge behaviour
    * Good tooling support (publishing in all directions)

So, for me it was natural to try to combine office like editing with Markdown files.

So, if you like, give it a try, it's free: I would be glad to get some feedback from you. Thank you.

Please be aware, that this is the first release, so there might be plenty of bugs and currently not all of Markdown's features are supported.



Markdown-Discuss mailing list
Markdown-Discuss <at>
Sean Leonard | 10 Sep 23:31 2014

New Version Notification for draft-ietf-appsawg-text-markdown-01.txt

Work on the text/markdown media type in the IETF is underway.

I wanted to post this to this discussion list to let you all know of the progress, and to welcome feedback. To
reiterate: this standards effort is to register `text/markdown` as the Internet media type for Markdown
content. It does not standardize the syntax in any way.

I have already gotten very substantial feedback privately, so thanks in advance for that. The draft is not
perfect, but it's a great place to start.

One piece of feedback that I thought was really important to state up front, is that draft-01 lacks a
discussion of goals and use cases that we want to satisfy. Therefore, I would like to invite the community
to contribute. Some things in the draft (like the whole `processor` thing) may make no sense for your use
case, but several others on this list have articulated reasons why they would want such things. I have set
up a wiki page so that the community can add this content: <>.

In addition to responding privately and responding on this list, here are some other resources:
IETF apps-discuss Mailing List:
Wiki for Goals and Uses: (just saying it twice for emphasis)



A new version of I-D, draft-ietf-appsawg-text-markdown-01.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-ietf-appsawg-text-markdown
Revision:	01
Title:		The text/markdown Media Type
Document date:	2014-09-09
Group:		appsawg
Pages:		14

    This document registers the text/markdown media type for use with
    Markdown, a family of plain text formatting syntaxes that optionally
    can be converted to formal markup languages such as HTML.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat

the trains are already leaving the station

i said:
>   and get on board this new, better model, with a good algorithm.
>   maybe the way you did it before was good enough for back then,
>   but the future _will_ leave you behind if you do not get on board.
>   _however_, you might want to wait, for maybe a month or two.
>   because macfarlane's _model_ isn't yet as clear as it should be...

well, maybe just maybe you shouldn't wait after all.

i'm sure the model will change, perhaps quite a bit,
but programmers are already stepping up to bat and
there are only so many converters that need coding.

in addition to "official" converters from john macfarlane
-- one of which is written in c, the other in javascript --
commonmark already has two more in other languages.

in php:

in c#:

hopefully the commonmark team will vet these converters,
to ensure they're currently accurate and will be maintained
-- not just to give correct results, but also _work_ correctly --
and prevent a flock of "me-too" forks muddying the waters...
a solid line of converters, sleek but complete, is all we need.

Andrei Fangli | 7 Sep 20:31 2014

Re: It's a Markdown processor, right?

Sean wrote:
> I am trying to use uniform terms. An implementation that converts
Markdown content to another format--most typically HTML--is called...a
Markdown processor, right?

I was focusing on naming the software that takes text in format A and outputs it in format B (yep, just that use case). The XML specifications define that a XML Processor is something that recognizes the structure of a XML Document, validates it and offers access to its content (e.g.: by tree traversal since XML is hierarchical in nature). A software that simply translates from format A to B only recognizes, validates the structure of the text in format A and outputs the content in format B. If we were to apply an analogous definition for a Markdown Processor then the access to content is lost because the initial document as a whole is outputted in format B without having the chance to peak at its content. In that case we cannot name that software a processor, it may use one internally to get the job done.

In the case of a software that allows visualisation of Markdown documents prior to translation/export, eventually allowing editing, indexing, word count, page count etc., I agree, that no longer can be called a translator because it does much more. That software falls well in the terms of a word processor (specialized for Markdown in this case) as pointed out, however I’m not sure that’s what Sean was asking.

This discussion is turning out quite interesting as parsers require a grammar in a formal language (e.g.: BNF) while a processor can be implemented from a description.

Andrei Fangli

From: Aristotle Pagaltzis
Sent: ‎Sunday‎, ‎7‎ ‎September‎ ‎2014 ‎20‎:‎53
To: markdown-discuss <at>

* Andrei Fangli <andrei_fangli <at>> [2014-09-07 10:45]:
> When I hear Markdown processor I think of a specialized word/text
> processor

That is not what it generally mean in RFCs. The XML specs speak of an
XML processor, the Atom RFCs speak of an Atom processor, etc. So I think
the terminology here is correct for an RFC.

(To me what you refer to is a “Markdown word processor”, esp considering
that a word processor is called a *word* processor rather than, say, an
RTF processor or a DOC processor.)

I’ll also defend the term on grounds of its meaning later, but let me
first address the proposed alternatives:

> For me, Markdown implementation sounds a bit odd. Markdown is not
> standardized nor is its specification clear enough


> I’d simply name the specification (or flavour) and append “Translator”
> at the end (e.g.: Github flavoured Markdown Translator, Common
> Markdown Translator etc.).

That is specific to a use case. E.g. multiple MacOS X QuickLook plugins
for Markdown preview exist; these are not translators, all they can do
is display the document (or a portion of it). Internally they may use
a translator, as most probably do, but they may just as well be written
on top of a Markdown parser that merely creates an AST rather than any
kind of output; either way it’s an implementation detail.

* Andrei Fangli <andrei_fangli <at>> [2014-09-07 17:00]:
> Parsing is all about syntactic analysis, a parser may well just return
> true and false depending on whether the input is syntactically correct
> or not.

Yes, agree: “parser” is not the right term.

It’s also not the right term because a translator need not necessarily
parse the document. doesn’t. So actually, “Markdown parser”
in fact excludes the canonical Markdown… processor.

> I’m not very comfortable about calling them libraries if they are
> actually executables or scripts.

Agree here also.


Ultimately, to come back to the beginning of my mail, what you want to
express is “a piece of software that will take Markdown and do something
with it in some Markdown-rules-informed way”. You want to cover any kind
of doing something, be it translating to another format or displaying
the document or extracting something from it (e.g. indexing or counting
words or whatever) or anything else. You want to cover any form in which
software comes, be that a library, an executable, or just an incidental
part of some larger library or application. And you want to allow for it
implementing any fraction of the total Markdown rules (e.g. a Markdown
word counter could ignore most inline formatting as punctuation without
it making a difference in the result), and in whichever form it chooses
(it could use parsing, or not).

I would argue that the only sufficiently generic term that will apply to
software in all of these cases is, in fact, “processor”.

Aristotle Pagaltzis // <>
Markdown-Discuss mailing list
Markdown-Discuss <at>
Markdown-Discuss mailing list
Markdown-Discuss <at>