kramdown 0.1.0 → 0.2.0
Sign up to get free protection for your applications and to get access to all the features.
Potentially problematic release.
This version of kramdown might be problematic. Click here for more details.
- data/COPYING +1 -1
- data/ChangeLog +423 -1
- data/Rakefile +5 -5
- data/VERSION +1 -1
- data/doc/default.template +4 -4
- data/doc/index.page +5 -4
- data/doc/news.feed +1 -1
- data/doc/quickref.page +72 -25
- data/doc/syntax.page +238 -66
- data/doc/tests.page +2 -3
- data/lib/kramdown/converter.rb +41 -10
- data/lib/kramdown/deprecated.rb +41 -0
- data/lib/kramdown/document.rb +17 -8
- data/lib/kramdown/extension.rb +13 -7
- data/lib/kramdown/parser.rb +263 -95
- data/lib/kramdown/version.rb +28 -0
- data/test/run_tests.rb +1 -1
- data/test/test_files.rb +1 -1
- data/test/testcases/block/02_eob/middle.html +1 -0
- data/test/testcases/block/04_header/atx_header.html +8 -0
- data/test/testcases/block/04_header/atx_header.text +8 -0
- data/test/testcases/block/04_header/setext_header.html +6 -0
- data/test/testcases/block/04_header/setext_header.text +9 -0
- data/test/testcases/block/07_horizontal_rule/sepspaces.html +3 -0
- data/test/testcases/block/07_horizontal_rule/sepspaces.text +3 -0
- data/test/testcases/block/07_horizontal_rule/septabs.html +3 -0
- data/test/testcases/block/07_horizontal_rule/septabs.text +3 -0
- data/test/testcases/block/09_html/content_model/deflists.html +6 -0
- data/test/testcases/block/09_html/content_model/deflists.options +1 -0
- data/test/testcases/block/09_html/content_model/deflists.text +6 -0
- data/test/testcases/block/09_html/content_model/tables.html +14 -0
- data/test/testcases/block/09_html/content_model/tables.options +1 -0
- data/test/testcases/block/09_html/content_model/tables.text +14 -0
- data/test/testcases/block/09_html/html_and_codeblocks.options +1 -1
- data/test/testcases/block/09_html/invalid_html_1.html +0 -2
- data/test/testcases/block/09_html/invalid_html_2.html +2 -3
- data/test/testcases/block/09_html/markdown_attr.html +38 -0
- data/test/testcases/block/09_html/markdown_attr.text +38 -0
- data/test/testcases/block/09_html/not_parsed.html +14 -0
- data/test/testcases/block/09_html/not_parsed.text +15 -0
- data/test/testcases/block/09_html/parse_as_raw.html +16 -14
- data/test/testcases/block/09_html/parse_as_raw.options +1 -0
- data/test/testcases/block/09_html/parse_as_raw.text +13 -1
- data/test/testcases/block/09_html/parse_as_span.html +2 -5
- data/test/testcases/block/09_html/parse_as_span.options +1 -0
- data/test/testcases/block/09_html/{auto_parse_block_html.html → parse_block_html.html} +0 -0
- data/test/testcases/block/09_html/parse_block_html.options +1 -0
- data/test/testcases/block/09_html/{auto_parse_block_html.text → parse_block_html.text} +0 -0
- data/test/testcases/block/09_html/simple.html +21 -30
- data/test/testcases/block/09_html/simple.options +1 -0
- data/test/testcases/block/09_html/simple.text +13 -2
- data/test/testcases/block/11_ial/auto_id_and_ial.html +1 -0
- data/test/testcases/block/11_ial/auto_id_and_ial.options +1 -0
- data/test/testcases/block/11_ial/auto_id_and_ial.text +2 -0
- data/test/testcases/block/12_extension/{nokramdown.html → nomarkdown.html} +0 -0
- data/test/testcases/block/12_extension/{nokramdown.text → nomarkdown.text} +4 -4
- data/test/testcases/block/12_extension/{kdoptions.html → options.html} +9 -0
- data/test/testcases/block/12_extension/options.text +28 -0
- data/test/testcases/block/12_extension/{kdoptions2.html → options2.html} +0 -0
- data/test/testcases/block/12_extension/{kdoptions2.text → options2.text} +1 -1
- data/test/testcases/block/13_definition_list/definition_at_beginning.html +1 -0
- data/test/testcases/block/13_definition_list/definition_at_beginning.text +1 -0
- data/test/testcases/block/13_definition_list/multiple_terms.html +13 -0
- data/test/testcases/block/13_definition_list/multiple_terms.text +10 -0
- data/test/testcases/block/13_definition_list/para_wrapping.html +10 -0
- data/test/testcases/block/13_definition_list/para_wrapping.text +6 -0
- data/test/testcases/block/13_definition_list/separated_by_eob.html +8 -0
- data/test/testcases/block/13_definition_list/separated_by_eob.text +5 -0
- data/test/testcases/block/13_definition_list/simple.html +8 -0
- data/test/testcases/block/13_definition_list/simple.text +7 -0
- data/test/testcases/block/13_definition_list/styled_terms.html +4 -0
- data/test/testcases/block/13_definition_list/styled_terms.text +2 -0
- data/test/testcases/block/13_definition_list/too_much_space.html +3 -0
- data/test/testcases/block/13_definition_list/too_much_space.text +4 -0
- data/test/testcases/block/13_definition_list/with_blocks.html +38 -0
- data/test/testcases/block/13_definition_list/with_blocks.text +24 -0
- data/test/testcases/span/05_html/across_lines.html +1 -0
- data/test/testcases/span/05_html/across_lines.text +2 -0
- data/test/testcases/span/05_html/link_with_mailto.html +1 -0
- data/test/testcases/span/05_html/link_with_mailto.text +1 -0
- data/test/testcases/span/05_html/markdown_attr.html +5 -0
- data/test/testcases/span/05_html/markdown_attr.text +5 -0
- data/test/testcases/span/05_html/normal.html +7 -0
- data/test/testcases/span/05_html/normal.text +7 -0
- metadata +56 -12
- data/test/testcases/block/09_html/auto_parse_block_html.options +0 -1
- data/test/testcases/block/12_extension/kdoptions.text +0 -18
data/VERSION
CHANGED
@@ -1 +1 @@
|
|
1
|
-
0.
|
1
|
+
0.2.0
|
data/doc/default.template
CHANGED
@@ -4,19 +4,19 @@
|
|
4
4
|
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
|
5
5
|
<meta name="author" content="Thomas Leitner" />
|
6
6
|
<meta name="copyright" content="2009 Thomas Leitner" />
|
7
|
-
<meta name="description" content="
|
8
|
-
<meta name="keywords" content="ruby
|
7
|
+
<meta name="description" content="kramdown is a fast, pure-Ruby Markdown-superset converter" />
|
8
|
+
<meta name="keywords" content="ruby, kramdown, markdown, text markup" />
|
9
9
|
<link href="{relocatable: default.css}" type="text/css" rel="stylesheet" media="screen,projection" />
|
10
10
|
<link href="{relocatable: news.atom}" type="application/atom+xml" rel="alternate" />
|
11
11
|
|
12
|
-
<title>{title:} |
|
12
|
+
<title>{title:} | kramdown</title>
|
13
13
|
</head>
|
14
14
|
<body>
|
15
15
|
<div id="layout">
|
16
16
|
|
17
17
|
<div id="header">
|
18
18
|
|
19
|
-
<h1 id="logo"><a href="{relocatable: /}" title="Homepage">
|
19
|
+
<h1 id="logo"><a href="{relocatable: /}" title="Homepage">kramdown <span class='slogan'>fast, pure-Ruby Markdown-superset converter</span></a></h1>
|
20
20
|
<hr class="noscreen" />
|
21
21
|
|
22
22
|
</div>
|
data/doc/index.page
CHANGED
@@ -73,15 +73,16 @@ and [mailing lists][ml] available if you have any questions!
|
|
73
73
|
|
74
74
|
## Welcome to the kramdown site
|
75
75
|
|
76
|
-
kramdown is a *free* GPL-licensed [Ruby](http://www.ruby-lang.org) library for parsing
|
77
|
-
|
78
|
-
and various extensions that have been made popular by the [PHP Markdown Extra]
|
76
|
+
kramdown is a *free* GPL-licensed [Ruby](http://www.ruby-lang.org) library for parsing a superset of
|
77
|
+
Markdown. It is completely written in Ruby, supports standard Markdown (with some minor
|
78
|
+
modifications) and various extensions that have been made popular by the [PHP Markdown Extra]
|
79
|
+
package and [Maruku].
|
79
80
|
|
80
81
|
It is probably the fastest pure-Ruby Markdown converter available (November 2009), being 5x faster
|
81
82
|
than [Maruku] and about 10x faster than [BlueFeather].
|
82
83
|
|
83
84
|
<div class="a-center">
|
84
|
-
The latest version of kramdown is <b>0.
|
85
|
+
The latest version of kramdown is <b>0.2.0</b> and it was released on <b>2009-12-03</b>.
|
85
86
|
</div>
|
86
87
|
|
87
88
|
[PHP Markdown Extra]: http://michelf.com/projects/php-markdown/extra/
|
data/doc/news.feed
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
---
|
2
2
|
title: kramdown News
|
3
|
-
description: kramdown - a fast, pure Ruby Markdown
|
3
|
+
description: kramdown - a fast, pure Ruby Markdown-superset converter
|
4
4
|
site_url: http://kramdown.rubyforge.org/
|
5
5
|
author: Thomas Leitner
|
6
6
|
author_url: http://kramdown.rubyforge.org
|
data/doc/quickref.page
CHANGED
@@ -5,9 +5,12 @@ sort_info: 9
|
|
5
5
|
---
|
6
6
|
# Quick Reference
|
7
7
|
|
8
|
-
Below are examples of all available structural elements that can be used in kramdown text.
|
9
|
-
|
10
|
-
|
8
|
+
Below are examples of all available structural elements that can be used in a kramdown text. Since
|
9
|
+
the kramdown syntax is a superset of the Markdown syntax, only a small part of the available syntax
|
10
|
+
is not available in standard Markdown syntax. Note, that only the most basic syntax information is
|
11
|
+
given. However, a link to the detailed syntax for each element is provided (which also details the
|
12
|
+
differences to the standard Markdown syntax). The quick reference is for version **<%=
|
13
|
+
Kramdown::VERSION %>** of the syntax documentation.
|
11
14
|
|
12
15
|
kramdown has two main classes of elements: block and span level elements. Block level elements are
|
13
16
|
used to create paragraphs, headers, lists and so on whereas span level elements are used to markup
|
@@ -16,18 +19,14 @@ text phrases as emphasized, as a link and so on.
|
|
16
19
|
All examples below feature the kramdown source, the converted HTML source and the output as it
|
17
20
|
appears in the browser. This looks like this:
|
18
21
|
|
19
|
-
{::nokramdown:}
|
20
22
|
<div class="kdexample">
|
21
|
-
<pre class="kdexample-before"><code>kramdown example code
|
22
|
-
</code></pre>
|
23
|
-
<pre class="kdexample-after-source"><code>Example code converted to HTML
|
24
|
-
</code></pre>
|
23
|
+
<pre class="kdexample-before"><code>kramdown example code</code></pre>
|
24
|
+
<pre class="kdexample-after-source"><code>Example code converted to HTML</code></pre>
|
25
25
|
<div class="kdexample-after-live">
|
26
26
|
Live browser view of example code
|
27
27
|
</div>
|
28
28
|
</div>
|
29
29
|
<div class="clear"></div>
|
30
|
-
{::nokramdown:}
|
31
30
|
|
32
31
|
|
33
32
|
# Block Level Elements - Main Structural Elements
|
@@ -81,16 +80,15 @@ Second level header
|
|
81
80
|
###### H6 header
|
82
81
|
{::kdexample:}
|
83
82
|
|
84
|
-
If you set the option `auto_ids` to `
|
85
|
-
[Extension Blocks](#extension-blocks)), then
|
86
|
-
the header text:
|
83
|
+
If you set the option `auto_ids` to `false` (for example, by using the `options` extension, see
|
84
|
+
[Extension Blocks](#extension-blocks)), then the automatic header ID generation is turned off:
|
87
85
|
|
88
86
|
{::kdexample:}
|
89
|
-
# A header
|
87
|
+
# A header with an ID
|
90
88
|
|
91
|
-
{::
|
89
|
+
{::options:: auto_ids="false"}
|
92
90
|
|
93
|
-
# A header
|
91
|
+
# A header without an ID
|
94
92
|
{::kdexample:}
|
95
93
|
|
96
94
|
|
@@ -211,18 +209,67 @@ space. Apart from that unordered lists follow the same rules as ordered lists:
|
|
211
209
|
- Item three
|
212
210
|
{::kdexample:}
|
213
211
|
|
212
|
+
## Definition Lists
|
213
|
+
|
214
|
+
{::kdlink:: #definition-lists part="definition lists"}
|
215
|
+
|
216
|
+
A definition list works similar to a normal list and is used to associate definitions with terms.
|
217
|
+
Definition lists are started when a normal paragraph is followed by a line starting with a colon and
|
218
|
+
then the definition text. One term can have many definitions and multiple terms can have the same
|
219
|
+
definition. Each line of the preceding paragraph is assumed to contain one term, for example:
|
220
|
+
|
221
|
+
{::kdexample:}
|
222
|
+
term
|
223
|
+
: definition
|
224
|
+
: another definition
|
225
|
+
|
226
|
+
another term
|
227
|
+
and another term
|
228
|
+
: and a definition for the term
|
229
|
+
{::kdexample:}
|
230
|
+
|
231
|
+
If you insert a blank line before a definition (note: there must only be one blank line between the
|
232
|
+
terms and the first definition), the definition will be wrapped in a paragraph:
|
233
|
+
|
234
|
+
{::kdexample:}
|
235
|
+
term
|
236
|
+
|
237
|
+
: definition
|
238
|
+
: definition
|
239
|
+
{::kdexample:}
|
240
|
+
|
241
|
+
Each term can be styled using span level elements and each definition is parsed as block level
|
242
|
+
elements, ie. you can use any block level in a definition. Just use the same indent for the lines
|
243
|
+
following the definition line:
|
244
|
+
|
245
|
+
{::kdexample:}
|
246
|
+
This *is* a term
|
247
|
+
|
248
|
+
: This will be a para
|
249
|
+
> a blockquote
|
250
|
+
|
251
|
+
# A header
|
252
|
+
{::kdexample:}
|
253
|
+
|
214
254
|
|
215
255
|
## HTML elements
|
216
256
|
|
257
|
+
{::kdlink:: #html-blocks part="HTML blocks"}
|
258
|
+
|
217
259
|
kramdown allows you to use block level HTML tags (`div`, `p`, `pre`, ...) to markup whole blocks of
|
218
|
-
text -- just start a line with a block level HTML tag.
|
219
|
-
|
260
|
+
text -- just start a line with a block level HTML tag. kramdown syntax is normally not processed
|
261
|
+
inside an HTML tag but this can be changed with the `parse_block_html` option. If this options is
|
262
|
+
set to `true`, then the content of a block level HTML tag is parsed by kramdown either as block
|
263
|
+
level or span level text, depending on the tag:
|
220
264
|
|
221
265
|
{::kdexample:}
|
222
266
|
<div style="float: right">
|
223
|
-
Something that stays right.
|
267
|
+
Something that stays right and is not wrapped in a para.
|
268
|
+
</div>
|
269
|
+
{::options:: parse_block_html="true"}
|
270
|
+
<div>
|
271
|
+
This is wrapped in a para.
|
224
272
|
</div>
|
225
|
-
Normal text flow.
|
226
273
|
<p>
|
227
274
|
This can contain only *span* level elements.
|
228
275
|
</p>
|
@@ -299,9 +346,9 @@ completely ignored.
|
|
299
346
|
{::comment:}
|
300
347
|
... paragraph continues here.
|
301
348
|
|
302
|
-
{::
|
349
|
+
{::nomarkdown:}
|
303
350
|
This is not parsed *by* kramdown
|
304
|
-
{::
|
351
|
+
{::nomarkdown:}
|
305
352
|
{::kdexample:}
|
306
353
|
|
307
354
|
As one can see from the above example, the syntax for extension blocks is virtually the same as for
|
@@ -311,13 +358,13 @@ body text and continues until a matching ending line (as in the example above).
|
|
311
358
|
used, then the extension does not have a body, for example:
|
312
359
|
|
313
360
|
{::kdexample:}
|
314
|
-
# Header without id
|
315
|
-
{::kdoptions:: auto_ids="true"}
|
316
|
-
|
317
361
|
# Header with id
|
318
|
-
{::
|
362
|
+
{::options:: auto_ids="false"}
|
319
363
|
|
320
364
|
# Header without id
|
365
|
+
{::options:: auto_ids="true"}
|
366
|
+
|
367
|
+
# Header with id
|
321
368
|
{::kdexample:}
|
322
369
|
|
323
370
|
|
data/doc/syntax.page
CHANGED
@@ -3,12 +3,13 @@ title: Syntax
|
|
3
3
|
in_menu: true
|
4
4
|
sort_info: 10
|
5
5
|
---
|
6
|
+
This is version **<%= Kramdown::VERSION %>** of the syntax documentation.
|
6
7
|
|
7
8
|
Table of Contents:
|
8
9
|
|
9
|
-
{::
|
10
|
+
{::nomarkdown:}
|
10
11
|
{menu: {used_nodes: fragments, min_levels: 3}}
|
11
|
-
{::
|
12
|
+
{::nomarkdown:}
|
12
13
|
|
13
14
|
# kramdown Syntax
|
14
15
|
|
@@ -120,13 +121,11 @@ meaning:
|
|
120
121
|
* When used in lists -- see the [lists section](#lists)
|
121
122
|
|
122
123
|
|
123
|
-
|
124
124
|
## End-Of-Block Marker
|
125
125
|
|
126
126
|
The End-Of-Block (EOB) marker -- a `^` as first character on an otherwise empty line -- can be used
|
127
127
|
to specify the end of a block level element even if the block level element, after which it is used,
|
128
|
-
would continue otherwise. If there is no block to end, the EOB marker is simply ignored
|
129
|
-
is considered a blank line.
|
128
|
+
would continue otherwise. If there is no block to end, the EOB marker is simply ignored.
|
130
129
|
|
131
130
|
You won't find an EOB marker in most kramdown documents but sometimes it is necessary to use it to
|
132
131
|
achieve the wanted results which would be impossible otherwise.
|
@@ -155,7 +154,7 @@ separate two consecutive paragraphs from each other by using one or more blank l
|
|
155
154
|
line break in the source does not mean a line break in the output. If you want to have an explicit
|
156
155
|
line break (ie. a `<br />` tag) you need to end a line with two or more spaces or two backslashes!
|
157
156
|
Note, however, that a line break on the last text line of a paragraph is not possible and will be
|
158
|
-
ignored.
|
157
|
+
ignored. Leading and trailing spaces will be stripped from the paragraph text.
|
159
158
|
|
160
159
|
The following gives you an example of how paragraphs look like:
|
161
160
|
|
@@ -173,6 +172,8 @@ The following gives you an example of how paragraphs look like:
|
|
173
172
|
|
174
173
|
kramdown supports Setext style and atx style headers.
|
175
174
|
|
175
|
+
### Setext Style
|
176
|
+
|
176
177
|
Setext style headers are specified by a blank line (except at the beginning of a document), a line
|
177
178
|
of text (the header text) followed by a line with only equal signs (for a first level header) or
|
178
179
|
dashes (for a second level header). The header text may be indented up to three spaces, any leading
|
@@ -221,6 +222,8 @@ One might ask if this represents two paragraphs separated by a horizontal line o
|
|
221
222
|
header and a paragraph. As suggested by the wording in the example, the latter is the case. The
|
222
223
|
general rule is that Setext headers are processed before horizontal rules.
|
223
224
|
|
225
|
+
### atx Style
|
226
|
+
|
224
227
|
atx style headers can be specified by a blank line (except at the beginning of a document), a line
|
225
228
|
with one or more hash characters and then the header text. No spaces are allowed before the hash
|
226
229
|
characters. The number of hash characters specifies the heading level: one hash character gives you
|
@@ -237,8 +240,11 @@ close the header. Any leading or trailing spaces are stripped from the header te
|
|
237
240
|
> Again, the original Markdown syntax allows one to omit the blank line before an atx style header.
|
238
241
|
{: .markdown-difference}
|
239
242
|
|
240
|
-
|
241
|
-
|
243
|
+
### Automatic Generation of Header IDs
|
244
|
+
|
245
|
+
kramdown supports the automatic generation of header IDs if the option `:auto_ids` is set to `true`
|
246
|
+
(which is the default). This is done by converting the untransformed, ie. plain, header text via the
|
247
|
+
following steps:
|
242
248
|
|
243
249
|
* All characters except letters, numbers, spaces and dashes are removed.
|
244
250
|
* All characters from the start of the line till the first letter are removed.
|
@@ -277,6 +283,24 @@ Following are some examples of header texts and their respective generated IDs:
|
|
277
283
|
> text is converted to an identifier are based on the rules specified by [Pandoc].
|
278
284
|
{: .markdown-difference}
|
279
285
|
|
286
|
+
### Manually Specifying a Header ID
|
287
|
+
|
288
|
+
Additionally, kramdown supports a nice way for setting the header ID which is available in [PHP
|
289
|
+
Markdown Extra] and [Maruku]: If you follow the header text with an opening curly bracket (separated
|
290
|
+
from the text with a least one space), a hash, the ID and a closing curly bracket, the ID is set on
|
291
|
+
the header. If you use the trailing hash feature of atx style headers, the header ID has to go after
|
292
|
+
the trailing hashes. For example:
|
293
|
+
|
294
|
+
Hello {#id}
|
295
|
+
-----
|
296
|
+
|
297
|
+
# Hello {#id}
|
298
|
+
|
299
|
+
# Hello # {#id}
|
300
|
+
|
301
|
+
> This additional syntax is not part of standard Markdown.
|
302
|
+
{: .markdown-difference}
|
303
|
+
|
280
304
|
|
281
305
|
## Blockquotes
|
282
306
|
|
@@ -330,6 +354,8 @@ Code blocks can be used to represent verbatim text like markup, HTML or a progra
|
|
330
354
|
syntax is parsed within a code block, only `<`, `>` and `&` are substituted by their respective HTML
|
331
355
|
counterparts. A code block is wrapped in both `<pre>` and `<code>` tags.
|
332
356
|
|
357
|
+
### Standard Code Block
|
358
|
+
|
333
359
|
A code block can be started by using four spaces or one tab and then the text of the code block. All
|
334
360
|
following lines that adhere to this syntax belong to the same code block. The indentation (four
|
335
361
|
spaces or one tab) is stripped from the text. Note that blank lines don't separate consecutive code
|
@@ -346,6 +372,12 @@ separate the two:
|
|
346
372
|
^
|
347
373
|
This one is separate.
|
348
374
|
|
375
|
+
### Fenced Code Block
|
376
|
+
|
377
|
+
> This alternative syntax is not part of the original Markdown syntax. The idea and syntax comes
|
378
|
+
> from the [PHP Markdown Extra] package.
|
379
|
+
{: .markdown-difference}
|
380
|
+
|
349
381
|
kramdown also supports an alternative syntax for code blocks which does not use indented blocks but
|
350
382
|
delimiting lines. The starting line needs to begin with three or more tilde characters (`~`) and the
|
351
383
|
closing line needs to have at least the number of tildes the starting line has. Everything between
|
@@ -368,9 +400,7 @@ example:
|
|
368
400
|
This type of code block is especially useful for copy-pasted code since you don't need to indent the
|
369
401
|
code.
|
370
402
|
|
371
|
-
|
372
|
-
> the [PHP Markdown Extra] package.
|
373
|
-
{: .markdown-difference}
|
403
|
+
### Showing Whitespace in a Code Block
|
374
404
|
|
375
405
|
If you add the class `show-whitespaces` to a code block (using a [block
|
376
406
|
IAL](#block_inline_attribute_lists)), all spaces are replaced with `⋅` and additionally spaces
|
@@ -389,10 +419,10 @@ Here is an example:
|
|
389
419
|
|
390
420
|
## Horizontal Rules
|
391
421
|
|
392
|
-
A horizontal rule is created by using three or more asterisks, dashes or underscores
|
393
|
-
separated by spaces or tabs, on an otherwise blank line. The first
|
394
|
-
optionally be indented up to three spaces. The following examples
|
395
|
-
create a horizontal rule:
|
422
|
+
A horizontal rule is created by using three or more asterisks, dashes or underscores (these may not
|
423
|
+
be mixed on one line), optionally separated by spaces or tabs, on an otherwise blank line. The first
|
424
|
+
asterisk, dash or underscore may optionally be indented up to three spaces. The following examples
|
425
|
+
show different possibilities to create a horizontal rule:
|
396
426
|
|
397
427
|
* * *
|
398
428
|
|
@@ -405,6 +435,11 @@ create a horizontal rule:
|
|
405
435
|
|
406
436
|
## Lists
|
407
437
|
|
438
|
+
kramdown provides syntax elements for creating ordered and unordered lists as well as definition
|
439
|
+
lists.
|
440
|
+
|
441
|
+
### Ordered and Unordered lists
|
442
|
+
|
408
443
|
Both ordered and unordered lists follow the same rules.
|
409
444
|
|
410
445
|
A list is started with a list marker (in case of unordered lists one of `+`, `-` or `*` -- you can
|
@@ -477,11 +512,12 @@ list text is followed by one or more blank lines, it will be wrapped in a paragr
|
|
477
512
|
* kram
|
478
513
|
|
479
514
|
* down
|
515
|
+
* now
|
480
516
|
|
481
517
|
In the above example, the first list item text will be wrapped in a paragraph tag since it is
|
482
|
-
followed by a blank line
|
483
|
-
|
484
|
-
using an EOB marker:
|
518
|
+
followed by a blank line whereas the second list item contains just text. There is obviously a
|
519
|
+
problem for doing this with the last list item when it contains only text. You can circumvent this
|
520
|
+
by leaving a blank line after the last list item and using an EOB marker:
|
485
521
|
|
486
522
|
* Not wrapped in a paragraph
|
487
523
|
* Wrapped in a paragraph due to the following blank line.
|
@@ -577,21 +613,112 @@ useful when the paragraph starts with something looking like a list item marker)
|
|
577
613
|
\- others say that, too!
|
578
614
|
|
579
615
|
|
616
|
+
### Definition Lists
|
617
|
+
|
618
|
+
> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
|
619
|
+
> the [PHP Markdown Extra] package.
|
620
|
+
{: .markdown-difference}
|
621
|
+
|
622
|
+
Definition lists allow you to assign one or more definitions to one or more terms.
|
623
|
+
|
624
|
+
A definition list is started when a normal paragraph is followed by a line with a definition marker
|
625
|
+
(a colon which may be optionally indented up to three spaces), then at least one tab or one space
|
626
|
+
and then the first part of the definition. The line with the definition marker may optionally be
|
627
|
+
separated from the preceding paragraph by a blank line. The leading tabs or spaces are stripped away
|
628
|
+
from this first line of the definition to allow for a nice alignment with the following definition
|
629
|
+
content. Each line of the preceding paragraph is taken to be a term and the lines separately parsed
|
630
|
+
as span level elements.
|
631
|
+
|
632
|
+
The following is a simple definition list:
|
633
|
+
|
634
|
+
kramdown
|
635
|
+
: A Markdown-superset converter
|
636
|
+
|
637
|
+
Maruku
|
638
|
+
: Another Markdown-superset converter
|
639
|
+
|
640
|
+
The column number of the first non-space character which appears after a definition marker on the
|
641
|
+
same line specifies the indentation that has to be used for the following lines of the definition.
|
642
|
+
If there is no such character, the indentation that needs to be used is four spaces or one tab. If
|
643
|
+
one of the following lines does not have the needed amount of indentation, it is not treated as part
|
644
|
+
of the defintion. The indentation is stripped from the definition and it (note that the definition
|
645
|
+
naturally also contains the content of the line with the definition marker) is processed as text
|
646
|
+
containing block level elements. If there is more than one definition, all other definition markers
|
647
|
+
for the term may be indented up to three spaces or the number of spaces used for the indentation of
|
648
|
+
the last definition minus one, whichever number is smaller. For example:
|
649
|
+
|
650
|
+
definition term 1
|
651
|
+
definition term 2
|
652
|
+
: This is the first line. Since the first non-space characters appears in column 3, all other
|
653
|
+
lines have to be indented 2 spaces sothat they first characters align. This tells kramdown
|
654
|
+
that the lines belong to the definition.
|
655
|
+
: This is the another defintion for the same term. It uses a different number of spaces
|
656
|
+
for indentation which is okay but should generally be avoided.
|
657
|
+
: The definition marker is indented 3 spaces which is allowed but should also be avoided.
|
658
|
+
|
659
|
+
So, while the above is possible and creates a definition list with two terms and three definitions
|
660
|
+
for them, it is not advised to use different (definition marker and definition) indents in the same
|
661
|
+
definition list!
|
662
|
+
|
663
|
+
The definition for a term is made up of text and/or block level elements. If a definition is *not*
|
664
|
+
preceded by a blank line, the first part of the definition will just be text if it would be a
|
665
|
+
paragraph otherwise:
|
666
|
+
|
667
|
+
definition term
|
668
|
+
: This definition will just be text because it would normally be a paragraph and the there is
|
669
|
+
no preceding blank line.
|
670
|
+
|
671
|
+
> although the defintion contains other block level elements
|
672
|
+
|
673
|
+
: This definition *will* be a paragraph since it is preceded by a blank line.
|
674
|
+
|
675
|
+
The rules about having any block level element as first element in a list item also apply to a
|
676
|
+
definition.
|
677
|
+
|
678
|
+
|
580
679
|
## HTML Blocks
|
581
680
|
|
582
681
|
There is no problem mixing HTML tags into a kramdown document. An HTML block is started when
|
583
|
-
kramdown encounters a line beginning with a
|
584
|
-
a general XML tag -- which may be indented up to three spaces.
|
585
|
-
|
586
|
-
|
587
|
-
block
|
588
|
-
that only correct XHTML is supported! This means that
|
589
|
-
of `<
|
682
|
+
kramdown encounters a line beginning with an HTML tag that is *not* a span level HTML tag (`div`,
|
683
|
+
`p`, `pre`, ...) -- or with a general XML tag -- which may be indented up to three spaces. After
|
684
|
+
that any combination of text and HTML tags are allowed, with HTML span tags being treated as text.
|
685
|
+
Each HTML block tag must appear completely on the line, it may not be broken across several lines!
|
686
|
+
If a block HTML tag is not closed on the same line, the HTML block continues till the HTML block
|
687
|
+
line with the corresponding closing tag. Note that only correct XHTML is supported! This means that
|
688
|
+
you have to use, for example, `<hr />` instead of `<hr>` (although kramdown tries to fix such things
|
689
|
+
if possible).
|
690
|
+
|
691
|
+
By default, kramdown does not parse HTML blocks, i.e. when a block level HTML tag is encountered
|
692
|
+
only HTML block lines are parsed and everything else is treated as raw text. This will be done until
|
693
|
+
the closing tag for the outermost HTML tag is found (or until the end of the document if the closing
|
694
|
+
HTML tag does not exist). However, this can be configured with the `:parse_block_html` option. If
|
695
|
+
this is set to `true`, then syntax parsing in HTML blocks is enabled. All the examples below assume
|
696
|
+
that `:parse_block_html` is set to `true`. It is also possible to enable/disable syntax parsing on a
|
697
|
+
tag per tag basis using the `markdown` attribute:
|
698
|
+
|
699
|
+
* If an HTML tag has an attribute `markdown="0"`, then no parsing (except parsing of HTML block
|
700
|
+
lines) is done inside that HTML tag.
|
701
|
+
|
702
|
+
* If an HTML tag has an attribute `markdown="1"`, then the default mechanism for parsing syntax in
|
703
|
+
this tag is used.
|
704
|
+
|
705
|
+
* If an HTML tag has an attribute `markdown="block"`, then the content of the tag is parsed as block
|
706
|
+
level elements.
|
707
|
+
|
708
|
+
* If an HTML tag has an attribute `markdown="span"`, then the content of the tag is parsed as span
|
709
|
+
level elements.
|
710
|
+
|
711
|
+
Note, however, that text that appears on an HTML block starting or ending line is not parsed as
|
712
|
+
block level element even if the rest of the HTML block is! It is parsed as span level text
|
713
|
+
nonetheless.
|
714
|
+
|
715
|
+
If an invalid closing tag is found on an HTML block line while no HTML block is active, it is
|
716
|
+
ignored.
|
590
717
|
|
591
718
|
> The original Markdown syntax specifies that an HTML block must start at the left margin, ie. no
|
592
719
|
> indentation is allowed. Also, the HTML block has to be surrounded by blank lines. Both
|
593
720
|
> restrictions are lifted for kramdown documents. Additionally, the original syntax does not allow
|
594
|
-
> you to use Markdown syntax in HTML blocks.
|
721
|
+
> you to use Markdown syntax in HTML blocks which is allowed with kramdown.
|
595
722
|
{: .markdown-difference}
|
596
723
|
|
597
724
|
Here is a simple example:
|
@@ -604,7 +731,7 @@ Here is a simple example:
|
|
604
731
|
^
|
605
732
|
<p>This is a para.</p>
|
606
733
|
<div>
|
607
|
-
|
734
|
+
<p>Something in here.</p>
|
608
735
|
</div>
|
609
736
|
<p>Other para.</p>
|
610
737
|
|
@@ -629,40 +756,47 @@ When you specify an HTML block don't forget that the first column does not chang
|
|
629
756
|
</div>
|
630
757
|
</div>
|
631
758
|
|
632
|
-
If you don't use valid XHTML tags, you won't get expected result
|
759
|
+
If you don't use valid XHTML tags, you sometimes won't get the expected result. However, kramdown
|
760
|
+
tries to fix broken HTML if possible (note the automatically closed `<hr />` tag):
|
633
761
|
|
634
762
|
This is a para.
|
635
763
|
<div>
|
636
|
-
Something is
|
637
|
-
|
764
|
+
Something is broken here.
|
765
|
+
<hr>
|
638
766
|
</div>
|
639
|
-
This
|
767
|
+
This is a para.
|
640
768
|
^
|
641
769
|
<p>This is a para.</p>
|
642
770
|
<div>
|
643
|
-
|
644
|
-
|
771
|
+
<p>Something is broken here.</p>
|
772
|
+
<hr />
|
645
773
|
</div>
|
646
|
-
This
|
774
|
+
<p>This is a para.</p>
|
647
775
|
|
648
776
|
Unclosed block level HTML tags are correctly closed at the end of the document to ensure correct
|
649
|
-
nesting and invalidly used end tags are
|
777
|
+
nesting and invalidly used end tags are removed from the output:
|
650
778
|
|
651
779
|
This is a para.
|
652
|
-
<div><div class="clear"
|
780
|
+
<div><div class="clear"></div>
|
653
781
|
Another para.
|
654
782
|
</p>
|
655
783
|
^
|
656
784
|
<p>This is a para.</p>
|
657
|
-
<div><div class="clear"
|
785
|
+
<div><div class="clear"></div>
|
658
786
|
<p>Another para.</p>
|
659
|
-
</p>
|
660
787
|
</div>
|
661
788
|
|
662
789
|
The content of a HTML tag is either parsed as block level elements, span level elements or is not
|
663
790
|
parsed at all depending on the tag encountered. For example, a `<div>` tag contains block level
|
664
791
|
elements, a `<p>` tag contains span level elements and the contents of a `<script>` tag is not
|
665
|
-
parsed at all.
|
792
|
+
parsed at all. General XML tags are also not parsed at all by default.
|
793
|
+
|
794
|
+
The following HTML tags count as span level HTML tags and *won't* start an HTML block if found on an
|
795
|
+
HTML block line. All other HTML tags and general XML tags will start an HTML block!
|
796
|
+
|
797
|
+
a abbr acronym b big bdo br button cite code del dfn em i img input
|
798
|
+
ins kbd label option q rb rbc rp rt rtc ruby samp select small span
|
799
|
+
strong sub sup textarea tt var
|
666
800
|
|
667
801
|
The parsing of processing instructions and XML comments is also supported. The content of both, PIs
|
668
802
|
and XML comments, may span multiple lines. The start of a PI/XML comment may only appear at the
|
@@ -677,7 +811,6 @@ comment till the end of the line are ignored. kramdown syntax in PIs/XML comment
|
|
677
811
|
Another para.
|
678
812
|
|
679
813
|
|
680
|
-
|
681
814
|
## Attribute List Definitions
|
682
815
|
|
683
816
|
> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
|
@@ -712,31 +845,31 @@ characters, digits or dashes.
|
|
712
845
|
There are four different types of attribute definitions which have to be separated by one or more
|
713
846
|
spaces:
|
714
847
|
|
715
|
-
|
848
|
+
references
|
716
849
|
|
717
|
-
|
850
|
+
: This must be a valid reference name. It is used to reference an other ALD sothat the attributes
|
718
851
|
of the other ALD are also included in this one. The reference name is ignored when collecting the
|
719
852
|
attributes if no attribute definition list with this reference name exists. For example, a
|
720
853
|
simple reference looks like `id`.
|
721
854
|
|
722
|
-
|
855
|
+
key-value pairs
|
723
856
|
|
724
|
-
|
857
|
+
: A key-value pair is defined by a key name, which must follow the rules for reference names, then
|
725
858
|
an equal sign and then the value in single or double quotes. If you need to use the value
|
726
859
|
delimiter (a single or a double quote) inside the value, you need to escape it with a backslash.
|
727
860
|
Key-value pairs can be used to specify arbitray attributes for block or span level elements. For
|
728
861
|
example, a key-value pair looks like `key1="bef \"quoted\" aft"` or `title='This is a title'`.
|
729
862
|
|
730
|
-
|
863
|
+
ID name
|
731
864
|
|
732
|
-
|
865
|
+
: An ID name is defined by using a hash and then the identifier name which must follow the rules
|
733
866
|
for reference names. This is a short hand for the key-value pair `id="IDNAME"` since this is
|
734
867
|
often used. The ID name specifies the unique ID of a block or span level element. For example,
|
735
868
|
an ID name looks like `#myid`.
|
736
869
|
|
737
|
-
|
870
|
+
class names
|
738
871
|
|
739
|
-
|
872
|
+
: A class name is definied by using a dot and then the class name. This is (almost, but not quite)
|
740
873
|
a short hand for the key-value pair `class="class-name"`. Almost because it actually means that
|
741
874
|
the class name should be appended to the current value of the `class` attribute. The following
|
742
875
|
ALDs are all equivalent:
|
@@ -781,25 +914,26 @@ Here are some examples for block IALs:
|
|
781
914
|
Some code here
|
782
915
|
{:.ruby}
|
783
916
|
|
784
|
-
TODO: special case for atx style headers.
|
785
|
-
|
786
917
|
|
787
918
|
## Extension Blocks
|
788
919
|
|
920
|
+
> This syntax feature is not part of the original Markdown syntax.
|
921
|
+
{: .markdown-difference}
|
922
|
+
|
789
923
|
Extension blocks can be used, for example, to treat whole sections of text specially. For example,
|
790
924
|
one could write an extension that highlights a code fragment specified in an extension block.
|
791
925
|
|
792
926
|
An extension block has two forms, one with a body and one without a body:
|
793
927
|
|
794
|
-
|
928
|
+
Without a body
|
795
929
|
|
796
|
-
|
930
|
+
: The extension block line has the same structure as an [ALD](#attribute_list_definitions) except
|
797
931
|
that the reference name needs to prefixed and postfixed with `:` and identifies the extension to
|
798
932
|
be used. Attributes can be defined like it is done for an ALD.
|
799
933
|
|
800
|
-
|
934
|
+
With a body
|
801
935
|
|
802
|
-
|
936
|
+
: The starting and ending lines of an extension block with a body have the same structure as an
|
803
937
|
[ALD](#attribute_list_definitions) except that the reference name needs to prefixed with `:` and
|
804
938
|
identifies the extension to be used; attributes can be defined on the starting or ending line.
|
805
939
|
The text between the starting and ending line is passed to the extension and not parsed by
|
@@ -809,17 +943,17 @@ An extension block has two forms, one with a body and one without a body:
|
|
809
943
|
If the specified extension is not found, a warning is shown and the whole extension block including
|
810
944
|
the body is ignored. The following extensions are builtin:
|
811
945
|
|
812
|
-
|
946
|
+
`comment`
|
813
947
|
|
814
|
-
|
948
|
+
: Treats the body text as a comment which does not show in the output.
|
815
949
|
|
816
|
-
|
950
|
+
`nomarkdown`
|
817
951
|
|
818
|
-
|
952
|
+
: The body is not processed with kramdown but output as-is.
|
819
953
|
|
820
|
-
|
954
|
+
`options`
|
821
955
|
|
822
|
-
|
956
|
+
: Should be used without a body since the body is ignored. Is used for setting options for the
|
823
957
|
kramdown processor (for example, to enable automatic header ID generation).
|
824
958
|
|
825
959
|
Here are some examples for how extension blocks look like:
|
@@ -848,6 +982,8 @@ output.
|
|
848
982
|
|
849
983
|
Two styles of links are supported: inline and reference.
|
850
984
|
|
985
|
+
### Inline Links
|
986
|
+
|
851
987
|
As the wording suggests, inline links provide all information inline in the text flow. Reference
|
852
988
|
style links only provide the link text in the text flow and everything else is defined
|
853
989
|
elsewhere. This also allows you to reuse link definitions.
|
@@ -873,6 +1009,8 @@ Notes:
|
|
873
1009
|
|
874
1010
|
* The link title may not contain its delimiters and may not be empty.
|
875
1011
|
|
1012
|
+
### Reference Links
|
1013
|
+
|
876
1014
|
To create a reference style link, you need to surround the link text with square brackets (as with
|
877
1015
|
inline links), followed by optional spaces/tabs/line breaks and then optionally followed with
|
878
1016
|
another set of square brackets with the link identifier in them. A link indentifier may only contain
|
@@ -888,6 +1026,8 @@ second pair of square brackets, the link text is converted to a valid link ident
|
|
888
1026
|
all invalid characters and inserting spaces for line breaks. If there is a link definition found for
|
889
1027
|
the link identifier, a link will be created. Otherwise the text is not converted to a link.
|
890
1028
|
|
1029
|
+
### Link Definitions
|
1030
|
+
|
891
1031
|
The link definition can be put anywhere in the document. It does not appear in the output. A link
|
892
1032
|
definition looks like this:
|
893
1033
|
|
@@ -909,6 +1049,8 @@ The link definition has the following structure:
|
|
909
1049
|
> allowed for consistency with the inline title.
|
910
1050
|
{: .markdown-difference}
|
911
1051
|
|
1052
|
+
### Images
|
1053
|
+
|
912
1054
|
Images can be specified via a syntax that is similar to the one used by links. The difference is
|
913
1055
|
that you have to use an exclamation mark before the first square bracket and that the link text of a
|
914
1056
|
normal link becomes the alternative text of the image link. As with normal links, image links can be
|
@@ -1001,15 +1143,45 @@ literal meaning of a backtick you can backslash-escape it:
|
|
1001
1143
|
HTML tags cannot only be used on the block level but also on the span level. Span level HTML tags
|
1002
1144
|
can only be used inside one block level element, it is not possible to use a start tag in one block
|
1003
1145
|
level element and the end tag in another. Note that only correct XHTML is supported! This means that
|
1004
|
-
you have to use, for example, `<br/>` instead of `<br>`.
|
1146
|
+
you have to use, for example, `<br />` instead of `<br>`.
|
1147
|
+
|
1148
|
+
By default, kramdown parses kramdown syntax inside HTML spans. However, this behaviour can be
|
1149
|
+
configured with the `:parse_span_html` option. If this is set to `true`, then syntax parsing in HTML
|
1150
|
+
spans is enabled, if it is set to `false`, parsing is disabled. It is also possible to
|
1151
|
+
enable/disable syntax parsing on a tag per tag basis using the `markdown` attribute:
|
1152
|
+
|
1153
|
+
* If an HTML tag has an attribute `markdown="0"`, then no parsing (except parsing of HTML span tags)
|
1154
|
+
is done inside that HTML tag.
|
1005
1155
|
|
1006
|
-
|
1156
|
+
* If an HTML tag has an attribute `markdown="1"`, then the content of the tag is parsed as span
|
1157
|
+
level elements.
|
1007
1158
|
|
1008
|
-
|
1009
|
-
|
1010
|
-
recognizes them as span level element and not as block level element.
|
1159
|
+
* If an HTML tag has an attribute `markdown="block"`, then a warning is issued because HTML spans
|
1160
|
+
cannot contain block level elements and the attribute is ignored.
|
1011
1161
|
|
1012
|
-
|
1162
|
+
* If an HTML tag has an attribute `markdown="span"`, then the content of the tag is parsed as span
|
1163
|
+
level elements.
|
1164
|
+
|
1165
|
+
The content of a span level HTML tag is normally parsed as span level elements. Note, however, that
|
1166
|
+
some tags like `<script>` are not parsed, i.e. their content is not modified.
|
1167
|
+
|
1168
|
+
Processing instructions and XML comments can also be used (their content is not parsed). However, as
|
1169
|
+
with HTML tags the start and the end have to appear in the same block level element.
|
1170
|
+
|
1171
|
+
Span level PIs and span level XML comments as well as general span level HTML and XML tags have to
|
1172
|
+
be preceded by at least one non whitespace character on the same line sothat kramdown correctly
|
1173
|
+
recognizes them as span level element and not as block level element. However, all span HTML tags,
|
1174
|
+
i.e. `a`, `em`, `b`, ..., (opening or closing) can appear at the start of a line.
|
1175
|
+
|
1176
|
+
Unclosed HTML tags as well as invalidly used end tags or block HTML tags are escaped.
|
1177
|
+
|
1178
|
+
Also note that one or more consecutive new line characters in an HTML span tag are replaced by a
|
1179
|
+
single space, for example:
|
1180
|
+
|
1181
|
+
Link: <a href="some
|
1182
|
+
link">text</a>
|
1183
|
+
^
|
1184
|
+
<p>Link: <a href="some link">text</a>
|
1013
1185
|
|
1014
1186
|
|
1015
1187
|
## Footnotes
|