markdown-testsuite 0.0.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 5dc4fc26b551a7b9560f234de9723a4cb23fd5ed
+  data.tar.gz: 0c3a3a35c2cc2fbfdfd6347d8ed90859acb18ac4
+SHA512:
+  metadata.gz: 6c635efec1abb68ef0fad377b485f3511015558b91e7fa1a9ca7cea6ea5b589e47d6c7c929521bde6877b80f9bfa61af1cd5e037dfb1d325eb86fe7f44f14478
+  data.tar.gz: 84eb02f2dab6386efacc8965cc89bad0e229742cb3621e56df2febe0559c0cf8309f46b4b11641405aa6f6c786ecf89b1ae608ec0d3f5d944beef5c190850551

data/.gitignore

@@ -0,0 +1,4 @@
+/all.tmp.md
+/config_local.py
+*.pyc
+*.gem

data/CONTRIBUTING.md

@@ -0,0 +1,109 @@
+# Contributing to Mardown Test Suite
+
+1. [Getting Involved](#getting-involved)
+2. [Discussion](#discussion)
+3. [How To Report an Issue](#how-to-report-an-issue)
+4. [Editing Markdown Specification](#editing-markdown-specification)
+5. [Test Suite Guidelines](#test-suite-guidelines)
+6. [Pull Request Guidelines](#pull-request-guidelines)
+
+## Getting Involved
+
+There are a number of ways to get involved with the development of the Markdown Test Suite. If you are a first time contributor to an open source project, you can still add value to this project. You may identify grammar issues, write prose, examples or documentation for the project. You may flag some errors and open new issues.
+
+Read all bits of this document and that will guide you on how to participate.
+
+## Discussion
+
+### Mailing List
+
+The Markdown Test Suite has been started a little bit after the start of the [Markdown Community Group](http://www.w3.org/community/markdown/). You may want to discuss about Markdown and this project on the [group mailing-list](http://lists.w3.org/Archives/Public/public-markdown/).
+
+## How to Report an Issue
+
+Don't be afraid to add details to your issue. The more context you give, the better for people participating to the project. Make a short summary, add a description with the context and give links to places which will help to understand.
+
+## Editing Markdown Specification
+
+There is much needed work on the [Markdown Specification](http://htmlpreview.github.io/?https://github.com/karlcow/markdown-testsuite/blob/master/markdown-spec.html). It doesn't require strong competences in coding. Be systematic in the markup and follow the way it is already organized. Each time you added a new atomic section, create a commit for this specific part.
+
+## Test Suite Guidelines
+
+When proposing new tests, make sure they do not already exist in the current test suite. You will notice that there is a separate section dedicated to the specific extensions that some markdown generators have created. Keep them separate. We want to keep the core clean and close to the original specification of Markdown.
+
+If you are not sure, create an issue.
+
+### Markdown Extensions
+
+Markdown extension tests are accepted. Use the following rules:
+
+- place all extension tests under the `test/extensions/ENGINE` directory with filename equal to the feature name
+- for each `ENGINE` and add a `README.markdown` under the engine directory with a link to its specification
+
+where `ENGINE` is either of:
+
+- a command line utility. E.g. `pandoc`, `kramdown`.
+- a programming API. E.g. `Redcarpet::Markdown.new()`.
+- a programmatically accessible web service. E.g.: GFM via the GitHub API.
+- a non programmatically accessible web service. E.g.: Stack Overflow flavored markdown.
+
+To avoid test duplication for common features, use the following rules:
+
+- if file `tests/extensions/ENGINE/FEATURE.md` is empty or not present, use `tests/extensions/FEATURE.md` instead
+- if file `tests/extensions/ENGINE/FEATURE.out` not present, use `tests/extensions/FEATURE.out` instead
+- for a given `ENGINE`, only features which have either a `.md` or a `.out` are implemented by that engine.
+- in case of different outputs for a single feature input, keep directly under `extensions/` only the output case that happens across the most engines
+
+**version**
+
+Only the latest stable version of each `ENGINE` is considered.
+
+**options**
+
+The IO behavior tested is for engine defaults, without any options (command line options, extra JSON parameters, etc.) passed to the engine.
+
+**external state**
+
+Tests that use external state not present in the markdown input shall not be included in this test suite.
+
+For example, what GFM `@user` user tags render to also depends on the state of GitHub's databases (only render to a link if user exists), not only on the input markdown.
+
+#### Examples
+
+GFM and the "fenced code block" use the following file structure:
+
+    tests/extensions/gfm/README.markdown
+    tests/extensions/gfm/fenced-code-block.md
+    tests/extensions/gfm/fenced-code-block.out
+
+where `README.markdown` contains:
+
+    https://help.github.com/articles/github-flavored-markdown
+
+To avoid duplication with other engines, if the input / output (normalized to DOM) is the same across multiple engines use:
+
+    tests/extensions/gfm/fenced-code-block.md       [empty]
+    tests/extensions/fenced-code-block.md
+    tests/extensions/fenced-code-block.out
+
+If the input is the same, and outputs are DOM different, but represent the same idea (e.g. both represent computer code) use:
+
+    tests/extensions/gfm/fenced-code-block.md       [empty]
+    tests/extensions/gfm/fenced-code-block.out
+    tests/extensions/fenced-code-block.md
+    tests/extensions/fenced-code-block.out
+
+#### New Extensions
+
+Tests are modular, and if you want to test a new engine for your project, that should be easy to do.
+
+If you feel that the new engine is reasonably popular, please send a pull request adding it.
+
+## Commits and Pull Requests
+
+* Keep your commits clean and commented
+* Do not mix in one commit different things. Keep modifications related.
+* Do not mix everything in one giant pull request. Create separate pull requests for different topic. That will help to have a more meaningful debate about the pull requests and will help to review the code.
+* If it relates to a specific issue, add the number of the issue in the commit message.
+
+Thanks for Contributing

data/Gemfile

@@ -0,0 +1,3 @@
+source 'https://rubygems.org'
+
+gemspec

data/LICENSE.md

@@ -0,0 +1,11 @@
+The MIT License (MIT)
+
+TestSuite - Copyright (c) 2013 Karl Dubost
+Ruby Fork - Copyright (c) 2013 Dave Kinkead
+
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -0,0 +1,40 @@
+# Markdown Test Suite
+
+## The Ruby Fork
+
+### Programatically test your markdown parser
+
+Inspired by questions on [W3C Markdown Community Group](http://www.w3.org/community/markdown).
+
+Pull Requests are welcome. To improve the `markdown-testsuite` rubygem, fork the ruby branch of this repo. See the [CONTRIBUTING Guidelines](https://github.com/karlcow/markdown-testsuite/blob/master/CONTRIBUTING.md) for additions to the markdown spec.
+
+## Usage
+
+First, install the gem and require it...
+
+    require 'markdown-testsuite'
+
+You can then list all the tests for the core spec...
+
+    Markdown::Testsuite.list
+    # => ["2-paragraphs-hard-return-spaces", "2-paragraphs-hard-return", ...]
+    
+Find out what extensions are supported...
+
+    Markdown::Testsuite.list :extensions
+    # => ["gfm", "kramdown", "multimarkdown", "pandoc", "redcarpet"]
+    
+Or list the tests for an extension...
+
+    Markdown::Testsuite.list :kramdown
+    # => ["fenced-code-block", "utf8"]
+    
+Then generate test objects for a rule, giving you access to its markdown and html form
+
+    img = Markdown::Testsuite.test 'img-title'
+    
+    img.md
+    # => "![HTML5](http://www.w3.org/html/logo/img/mark-word-icon.png \"HTML5 logo for everyone\")"
+    
+    img.html
+    # => "<p><img src=\"http://www.w3.org/html/logo/img/mark-word-icon.png\" alt=\"HTML5\" title=\"HTML5 logo for everyone\" /></p>"

data/Rakefile

@@ -0,0 +1,9 @@
+#require "bundler/gem_tasks"
+require 'rake'
+
+task default: [:specs]
+
+namespace :specs do
+  $LOAD_PATH.unshift('lib', 'specs')
+  Dir.glob('specs/**/*spec.rb').each { |file| require_relative file }
+end

data/lib/markdown-testsuite.rb

@@ -0,0 +1,71 @@
+require "markdown/testsuite/version"
+
+module Markdown
+  module Testsuite
+        
+    # Public: Lists all available tests or extensions
+    #
+    # filter_by - The extension as a Symbol
+    #
+    # Examples
+    #
+    #   Markdown::Testsuite.list
+    #   # => ["2-paragraphs-hard-return-spaces", "2-paragraphs-hard-return", ...]
+    #
+    #   Markdown::Testsuite.list :extensions
+    #   # => ["gfm", "kramdown", "multimarkdown", "pandoc", "redcarpet"]
+    #
+    #   Markdown::Testsuite.list :kramdown
+    #   # => ["fenced-code-block", "utf8"]
+    #    
+    # Returns the an Array.
+    def self.list(filter_by=:core)
+      tests = []
+      
+      if filter_by == :core
+        Dir.glob("#{SPEC_PATH}/*.md").each do |file|
+          file[/specification\/(.+?).md/]
+          tests << $1
+        end
+      else
+        extensions = Dir.glob("#{SPEC_PATH}/extensions/*").map do |file|
+          if File.directory? file
+            file[/specification\/extensions\/(.+?)$/]
+            $1
+          end
+        end
+        extensions.compact!.uniq!
+        
+        if filter_by == :extensions
+          tests = extensions
+        elsif
+          Dir.glob("#{SPEC_PATH}/extensions/#{filter_by.to_s}/*.md").each do |file|
+            file[/specification\/extensions\/#{filter_by.to_s}\/(.+?).md/]
+            tests << $1
+          end
+        end
+      end
+      tests
+    end
+    
+    # Public: Creates a test object for a rule
+    #
+    # rule - A String naming the rule
+    # ext  - A Symbol naming the extension
+    #
+    # Examples
+    #
+    #   Markdown::Testsuite.test 'img-title'
+    #   # => #<Markdown::Testsuite::Test:0x007fc633986240
+    #
+    #   Markdown::Testsuite.test 'uf8', :gfm
+    #   # => #<Markdown::Testsuite::Test:0x007fc553986240
+    #
+    #    
+    # Returns a Test object.
+    def self.test(rule, ext=nil)
+      Markdown::Testsuite::Test.new rule, ext
+    end
+    
+  end
+end

data/lib/markdown/testsuite/test.rb

@@ -0,0 +1,20 @@
+require 'markdown/testsuite/version'
+
+module Markdown
+  module Testsuite
+    class Test
+      
+      attr_reader :md, :html
+      
+      def initialize(rule, ext=nil)
+        path = ext.nil? ? "#{SPEC_PATH}/" : "#{SPEC_PATH}/extensions/#{ext.to_s}/"
+        begin
+          @md   = File.read "#{path}#{rule}.md"
+          @html = File.read "#{path}#{rule}.out"
+        rescue Exception => e 
+          raise Exception.new "Rule #{rule} not found - #{e}"
+        end
+      end
+    end
+  end
+end

data/lib/markdown/testsuite/version.rb

@@ -0,0 +1,8 @@
+require "markdown/testsuite/test"
+
+module Markdown
+  module Testsuite
+    VERSION = "0.0.0"
+    SPEC_PATH = File.expand_path('../../../../specification', __FILE__)
+  end
+end

data/markdown-spec.html

@@ -0,0 +1,315 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Markdown Syntax Specification</title>
+    <meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
+    <script src='http://darobin.github.com/respec/builds/respec-w3c-common.js' class='remove'></script>
+    <script class='remove'>
+      var respecConfig = {
+          // document info
+          specStatus:           "unofficial",
+          shortName:            "markdown",
+          // publishDate:   "2009-08-06",
+          // previousMaturity: "WD",
+          // previousPublishDate:  "2009-03-15",
+          // previousURI : "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
+          copyrightStart:       "2012",
+          edDraftURI:           "http://htmlpreview.github.io/?https://github.com/karlcow/markdown-testsuite/blob/master/markdown-spec.html",
+          // lcEnd:  "2010-08-06",
+
+          // editors
+          editors:  [
+              { name: "Karl Dubost", url: "http://www.la-grange.net/karl/",
+                company: "Mozilla", companyURL: "http://www.mozilla.org/" },
+          ],
+
+          // WG
+          wg:           "Markdown Community Group",
+          wgURI:        "http://www.w3.org/community/markdown/",
+          wgPublicList: "public-markdown",
+          wgPatentURI:  "",
+      };
+    </script>
+  </head>
+  <body>
+    <section id='abstract'>
+      This specification defines the Markdown syntax, a very simple text markup for giving a minimum of structure to a text and still making it readable.
+    </section>
+
+    <section id='sotd'>
+      <p>
+        This document has not been approved by any group yet. The intent is to produce a strawmann document which can be used by the <a href="http://www.w3.org/community/markdown/">Markdown Community Group</a> for defining what should be in a Markdown Specification.
+      </p>
+    </section>
+
+    <section class='informative'>
+      <h2>Introduction</h2>
+      <p>
+        <dfn>Markdown</dfn> is a text syntax created by John Gruber. etc. The content of the markup defined in this document is based on the initial Markdown Syntax as defined by John Gruber. The document might address syntax extension later on.
+      </p>
+    </section>
+
+    <section id='conformance'>
+      <h2>Conformance Section</h2>
+      <ul>
+        <li>author: (including authoring tools)</li>
+        <li>Markdown parser: </li>
+        <li>HTML producer: </li>
+      </ul>
+      <p class="issue">Define what/who implements the specification.</p>
+    </section>
+
+<section>
+<h2>Syntax</h2>
+<!--template for writing a feature of the language
+<h3>Feature name</h3>
+
+<p>A <dfn>feature</dfn> is… [description].</p>
+
+<h4 class="informative">Examples</h4>
+
+<pre class="example">Example code</pre>
+
+<h4>Processing</h4>
+
+<p>How a parser should process the feature.@describe the step and the unicode character.</p>
+
+<p class="issue">Describe Issue</p>
+
+<h4>HTML output</h4>
+
+<p>What should be the output</p>
+
+-->
+
+<h3>End Of Line (EOL) sequence</h3>
+
+<p>An <dfn>EOL sequence</dfn> consists of all characters and character sequences which can indicate the end of a line of input in a Markdown file.</p>
+
+<h4>Processing</h4>
+
+<p>An EOL sequence is defined as any of the following character sequences:</p>
+
+<ul>
+  <li>LF: Line Feed, U+000A
+  <li>CR: Carriage Return, U+000D
+  <li>CR+LF: CR (U+000D) followed by LF (U+000A)
+</ul>
+
+<h5 class="minisuite">Test Cases</h5>
+
+<ul class="tests">
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/EOL-LF.md">Lines end with LF</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/EOL-CR.md">Lines end with CR</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/EOL-CR+LF.md">Lines end with CR+LF</a></li>
+</ul>
+
+<p class="issue">Should all Unicode characters considered to mean the end of the line be recognized? (see <a href="http://en.wikipedia.org/wiki/Newline">Wikipedia Newline article</a>)</p>
+<p class="issue">As far as I can tell, embedding different EOL characters in a single text document is not doable by me.  I've created separate files to test, but that leaves us in the cold re: example text for this definition.  I've included tests for each EOL (to make sure they are detected properly).</p>
+
+<h4>HTML output</h4>
+
+<p>The output will be dependent on the block-level element being processed.  See (list of block-elements and cross-referenctial anchor tags goes here) for more information.</p>
+
+<p>For purposes of illustration, all the tests above should result in the following (identical) output.</p>
+
+<pre>
+<p>These lines all end with end of line (EOL) sequences.</p>
+
+<p>Seriously, they really do.</p>
+
+<p>If you don't believe me: HEX EDIT!</p>
+</pre>
+
+<h3>Standalone Paragraph</h3>
+
+<p>A <dfn>standalone paragraph</dfn> is a unit of text on one or more contiguous lines. Authors can use 0 to 3 leading spaces and 1 trailing space.</p>
+
+<h4 class="informative">Examples</h4>
+
+<pre class="example">This is a paragraph on a single line.
+
+This is another paragraph
+but on multiple lines.
+
+ This is another way
+ to create paragraphs
+ with leading spaces.</pre>
+
+<h4>Processing</h4>
+
+<p>A paragraph starts with 0 to 3 spaces (U+0020) followed by any characters, except the following characters <code>*</code> (U+002A), <code>-</code> (U+002D), <code>+</code> (U+002B), <code>></code>(U+003E).</p>
+
+<p>A paragraph ends with an EOL sequence followed by:</p>
+
+<ul>
+  <li>any spaces or tabs and another EOL sequence.</li>
+  <li>or End Of File</li>
+</ul>
+
+<p class="issue">Should a parser remove the leading characters spaces.</p>
+<p class="issue">To test tabs at the ends of a carriage return. See paragraph-trailing-tab.md test.</p>
+<p class="issue">What is happening to a multiline paragraph when converted to HTML? normalize as a long line, kept as is with the carriage return? What about eventual leading and trailing spaces.</p>
+
+<h5 class="minisuite">Test Cases</h5>
+
+<ul class="tests">
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraph-hard-return.md">Multilines paragraph</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraph-line.md">Paragraph on a single long line</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraph-trailing-leading-spaces.md">Paragraph with 1 leading space and 1 trailing space</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraph-trailing-tab.md">Paragraph with 1 trailing tab</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraphs-leading-space.md">Paragraph with 1 leading space</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraphs-2-leading-spaces.md">Paragraph with 2 leading spaces</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraphs-3-leading-spaces.md">Paragraph with 3 leading spaces</a></li>
+<li><a href="https://github.com/karlcow/markdown-testsuite/blob/master/tests/paragraphs-trailing-spaces.md">Paragraph with 1 trailing space</a></li>
+</ul>
+
+<h4>HTML output</h4>
+
+<p>An HTML producer MUST output a <code>P</code> element start tag followed by the content and MUST end with the <code>P</code> element end tag.</p>
+
+<p class="issue">Addressing the trailing/leading space characters in the processing or in the HTML output. Maybe better in the processing section to be able to produce in more than one format.</p>
+
+<h3>Line break</h3>
+
+<p>A <dfn>line break</dfn> is a way for authors to break a paragraph in the middle. Authors can use two trailing spaces and a return at the end of a line to insert a line break in a paragraph.</p>
+
+<h4 class="informative">Examples</h4>
+<pre class="example">This is a paragraph␠␠
+with an effective line break.</pre>
+
+<h4>Processing</h4>
+
+<p>A line break is created when there are two trailing spaces characters (U+0020) followed by an EOL sequence.</p>
+
+<p class="issue">To test what is happening with 3 or more trailing spaces.</p>
+<p class="issue">To test what is happening when this is the end of the paragraph. Should it be removed or kept.</p>
+
+<h4>HTML output</h4>
+
+<p>An HTML producer MUST output a <code>BR</code> element.</p>
+
+<h3>Headings</h3>
+
+<p>A <dfn>heading</dfn> is a string of text for marking up headings with 1 to 6 levels. The heading must be on one and only one line. It must not have any leading space characters. There are 3 ways of marking up headings.</p>
+
+<dl>
+<dt>Leading Hash sign</dt>
+<dd>The author must must put hash sign (<code>#</code>) at the beginning of the line followed by 0 or 1 space and the heading string. 1 hash sign for a level 1 heading to 6 hash signs for a level 6 heading.</dd>
+<dt>Nesting Hash sign</dt>
+<dd>In addition to the previous rules for leading hash sign, the author must close with 0 to 1 space and the same number of hash signs <code>#</code>.</dd>
+<dt>Underlines (<strong>level 1 and 2 only</strong>)</dt>
+<dd>For level 1 heading, the author must put at the next line after the heading string a series of equal signs (<code>=</code>) of the same length than the heading.</dd>
+<dd>For level 2 heading, the author must put at the next line after the heading string a series of dash signs (<code>-</code>) of the same length than the heading.</dd>
+</dl>
+
+<h4 class="informative">Examples</h4>
+
+<pre class="example">
+# Heading level 1
+## Heading level 2
+### Heading level 3
+#### Heading level 4
+##### Heading level 5
+###### Heading level 6
+
+# Heading level 1 #
+## Heading level 2 ##
+### Heading level 3 ###
+#### Heading level 4 ####
+##### Heading level 5 #####
+###### Heading level 6 ######
+
+Heading level 1
+===============
+
+Heading level 2
+---------------
+</pre>
+
+<h4>Processing</h4>
+
+<p>.</p>
+
+<p class="issue">trailing hash signs are not significant. This has to be explained clearly in the processing part.</p>
+<p class="issue">leading spaces are forbidden. To check.</p>
+<p class="issue">Is the length of the undeline string (=, -) significant. To check. Seems not.</p>
+<p class="issue">Verify the combination of # and underline markup.</p>
+
+<h4>HTML output</h4>
+
+<p>What should be the output</p>
+
+<h3>Reserved characters</h3>
+
+<p><dfn>Reserved characters</dfn> are used for marking up a markdown prose in some circumstances. It includes backtick <code>`</code>, asterisk <code>*</code>,
+ underscore <code>_</code>, curly braces <code>
+{}</code>code>, square brackets<code>[]</code>, parentheses <code>()</code>, hash mark <code>#</code>,  plus sign <code>+</code>, minus sign (hyphen) <code>-</code>, dot <code>.</code>, exclamation mark <code>!</code>. Their behavior is dependent of the position in the text. Authors can escape these characters with a backslash character (<code>\</code>)</p>
+
+<h4 class="informative">Examples</h4>
+
+<pre class="example">\\   backslash
+\`   backtick
+\*   asterisk
+\_   underscore
+\{\}  curly braces
+\[\]  square brackets
+\(\)  parentheses
+\#   hash mark
+\+   plus sign
+\-   minus sign (hyphen)
+\.   dot
+\!   exclamation mark</pre>
+
+<h4>Processing</h4>
+
+<p>How a parser should process the feature.@describe the step and the unicode character.</p>
+
+<p class="issue">Describe precisely when the characters is not escaped.</p>
+<p class="issue">Tests Needed for different circumstances.</p>
+
+<h4>HTML output</h4>
+
+<p>The producer tool must output the reserved characters as it is defined.</p>
+
+</section>
+
+<section>
+<h2>Markdown filename extension</h2>
+
+<p>An extension filename is a common way to identify a file on a Operating System and for authoring tools. Currently there are a number of extensions which have been used in the wild for handling markdown documents. Here is a list of some of these</p>
+
+<ul>
+  <li>.md</li>
+  <li>.mdown</li>
+  <li>.markdown</li>
+  <li>.mkd</li>
+  <li>.markdn</li>
+</ul>
+
+<p class="issue">Should there be only one normative extension filename for everyone to use? And make a note for deprecating the others as parseable but not conformant for producing tools.</p>
+
+</section>
+
+<section class="informative">
+
+<h2>Markup layout style guidelines</h2>
+<p>Authors and authoring tools are encouraged to use a fixed-width font for editing markdown document. It will be a lot easier to read and write.</p>
+
+</section>
+
+<section class='appendix'>
+<h2>Acknowledgements</h2>
+
+<p>The editor would like to thank the following persons for contributing and helping in creating this document</p>
+
+<ul>
+  <li>Many thanks to <a href="http://daringfireball.net/">John Gruber</a> for creating the initial version of <a href="http://daringfireball.net/projects/markdown/">Markdown Syntax</a>.</li>
+  <li>Jeff Atwood for calling out on stabilizing the Markdown syntax. @@link to blog post@@</li>
+  <li><a href="http://www.dpawson.co.uk">Dave Pawson</a> for proposing the W3C Markdown Community Group.</li>
+  <li><a href="http://johnmacfarlane.net/babelmark2/">Babelmark2</a> by <a href="http://johnmacfarlane.net/">John MacFarlane</a> has been essential to stay in sync with the reality of current implementations.</li>
+</ul>
+</section>
+
+</body>
+</html>