导航

6. Inlines

Inlines are parsed sequentially from the beginning of the character stream to the end (left to right, in left-to-right languages). Thus, for{panels}, in

hilo` .

hilo`

hi is parsed as code, leaving the backtick at the end as a literal backtick.

6.1. Code spans

A backtick string is a string of one or more backtick characters (`) that is neither preceded nor followed by a backtick.

A code span begins with a backtick string and ends with a backtick string of equal length. The contents of the code span are the characters between these two backtick strings, normalized in the following ways:

  • First, [line endings] are converted to [spaces].

  • If the resulting string both begins and ends with a [space] character, but does not consist entirely of [space] characters, a single [space] character is removed from the front and back. This allows you to include code that begins or ends with backtick characters, which must be separated by whitespace from the opening or closing backtick strings.

This is a simple code span:

foo .

foo

Here two backticks are used, because the code contains a backtick. This{panels} also illustrates stripping of a single leading and trailing space:

foo ` bar .

foo ` bar

This{panels} shows the motivation for stripping leading and trailing spaces:

`` .

``

Note that only one space is stripped:

`` .

``

The stripping only happens if the space is on both sides of the string:

a .

a

Only [spaces], and not [unicode whitespace] in general, are stripped in this way:

 b  .

 b 

No stripping occurs if the code span contains only spaces:

  .

 

[Line endings] are treated like spaces:

foo bar   baz .

foo bar baz

foo .

foo

Interior spaces are not collapsed:

foo   bar  baz .

foo bar baz

Note that browsers will typically collapse consecutive spaces when rendering <code> elements, so it is recommended that the following CSS be used:

code{white-space: pre-wrap;}

Note that backslash escapes do not work in code spans. All backslashes are treated literally:

foo\bar` .

foo\bar`

Backslash escapes are never needed, because one can always choose a string of n backtick characters as delimiters, where the code does not contain any strings of exactly n backtick characters.

foo`bar .

foo`bar

foo `` bar .

foo `` bar

Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks. Thus, for{panels}, this is not parsed as emphasized text, since the second * is part of a code span:

*foo* .

*foo*

And this is not parsed as a link:

[not a link](/foo) .

[not a link](/foo)

Code spans, HTML tags, and autolinks have the same precedence. Thus, this is code:

<a href="”>` .

<a href="">`

But this is an HTML tag:

` .

`

And this is code:

<http://foo.bar.baz>` .

<http://foo.bar.baz>`

But this is an autolink:

http://foo.bar.%60baz` .

http://foo.bar.`baz`

When a backtick string is not closed by a matching backtick string, we just have literal backticks:

```foo`` .

```foo``

`foo .

`foo

The following case also illustrates the need for opening and closing backtick strings to be equal in length:

`foobar .

`foobar

6.2. Emphasis and strong emphasis

John Gruber’s original Markdown syntax description says:

Markdown treats asterisks (*) and underscores (_) as indicators of emphasis. Text wrapped with one * or _ will be wrapped with an HTML <em> tag; double *’s or _’s will be wrapped with an HTML <strong> tag.

This is enough for most users, but these rules leave much undecided, especially when it comes to nested emphasis. The original Markdown.pl test suite makes it clear that triple *** and ___ delimiters can be used for strong emphasis, and most implementations have also allowed the following patterns:

***strong emph***
***strong** in emph*
***emph* in strong**
**in strong *emph***
*in emph **strong***

The following patterns are less widely supported, but the intent is clear and they are useful (especially in contexts like bibliography entries):

*emph *with emph* in it*
**strong **with strong** in it**

Many implementations have also restricted intraword emphasis to the * forms, to avoid unwanted emphasis in words containing internal underscores. (It is best practice to put these in code spans, but users often do not.)

internal emphasis: foo*bar*baz
no emphasis: foo_bar_baz

The rules given below capture all of these patterns, while allowing for efficient parsing strategies that do not backtrack.

First, some definitions. A delimiter run is either a sequence of one or more * characters that is not preceded or followed by a non-backslash-escaped * character, or a sequence of one or more _ characters that is not preceded or followed by a non-backslash-escaped _ character.

A left-flanking delimiter run is a [delimiter run] that is (1) not followed by [Unicode whitespace], and either (2a) not followed by a [Unicode punctuation character], or (2b) followed by a [Unicode punctuation character] and preceded by [Unicode whitespace] or a [Unicode punctuation character]. For purposes of this definition, the beginning and the end of the line count as Unicode whitespace.

A right-flanking delimiter run is a [delimiter run] that is (1) not preceded by [Unicode whitespace], and either (2a) not preceded by a [Unicode punctuation character], or (2b) preceded by a [Unicode punctuation character] and followed by [Unicode whitespace] or a [Unicode punctuation character]. For purposes of this definition, the beginning and the end of the line count as Unicode whitespace.

Here are some{panels}s of delimiter runs.

  • left-flanking but not right-flanking:

    ***abc
  _abc
**"abc"
 _"abc"

  • right-flanking but not left-flanking:

     abc***
 abc_
"abc"**
"abc"_

  • Both left and right-flanking:

     abc***def
"abc"_"def"

  • Neither left nor right-flanking:

    abc *** def
a _ b

(The idea of distinguishing left-flanking and right-flanking delimiter runs based on the character before and the character after comes from Roopesh Chander’s vfmd. vfmd uses the terminology “emphasis indicator string” instead of “delimiter run,” and its rules for distinguishing left- and right-flanking runs are a bit more complex than the ones given here.)

The following rules define emphasis and strong emphasis:

  1. A single * character can open emphasis iff (if and only if) it is part of a [left-flanking delimiter run].

  2. A single _ character [can open emphasis] iff it is part of a [left-flanking delimiter run] and either (a) not part of a [right-flanking delimiter run] or (b) part of a [right-flanking delimiter run] preceded by a [Unicode punctuation character].

  3. A single * character can close emphasis iff it is part of a [right-flanking delimiter run].

  4. A single _ character [can close emphasis] iff it is part of a [right-flanking delimiter run] and either (a) not part of a [left-flanking delimiter run] or (b) part of a [left-flanking delimiter run] followed by a [Unicode punctuation character].

  5. A double ** can open strong emphasis iff it is part of a [left-flanking delimiter run].

  6. A double __ [can open strong emphasis] iff it is part of a [left-flanking delimiter run] and either (a) not part of a [right-flanking delimiter run] or (b) part of a [right-flanking delimiter run] preceded by a [Unicode punctuation character].

  7. A double ** can close strong emphasis iff it is part of a [right-flanking delimiter run].

  8. A double __ [can close strong emphasis] iff it is part of a [right-flanking delimiter run] and either (a) not part of a [left-flanking delimiter run] or (b) part of a [left-flanking delimiter run] followed by a [Unicode punctuation character].

  9. Emphasis begins with a delimiter that [can open emphasis] and ends with a delimiter that [can close emphasis], and that uses the same character (_ or *) as the opening delimiter. The opening and closing delimiters must belong to separate [delimiter runs]. If one of the delimiters can both open and close emphasis, then the sum of the lengths of the delimiter runs containing the opening and closing delimiters must not be a multiple of 3 unless both lengths are multiples of 3.

  10. Strong emphasis begins with a delimiter that [can open strong emphasis] and ends with a delimiter that [can close strong emphasis], and that uses the same character (_ or *) as the opening delimiter. The opening and closing delimiters must belong to separate [delimiter runs]. If one of the delimiters can both open and close strong emphasis, then the sum of the lengths of the delimiter runs containing the opening and closing delimiters must not be a multiple of 3 unless both lengths are multiples of 3.

  11. A literal * character cannot occur at the beginning or end of *-delimited emphasis or **-delimited strong emphasis, unless it is backslash-escaped.

  12. A literal _ character cannot occur at the beginning or end of _-delimited emphasis or __-delimited strong emphasis, unless it is backslash-escaped.

Where rules 1–12 above are compatible with multiple parsings, the following principles resolve ambiguity:

  1. The number of nestings should be minimized. Thus, for{panels}, an interpretation <strong>...</strong> is always preferred to <em><em>...</em></em>.

  2. An interpretation <em><strong>...</strong></em> is always preferred to <strong><em>...</em></strong>.

  3. When two potential emphasis or strong emphasis spans overlap, so that the second begins before the first ends and ends after the first ends, the first takes precedence. Thus, for{panels}, *foo _bar* baz_ is parsed as <em>foo _bar</em> baz_ rather than *foo <em>bar* baz</em>.

  4. When there are two potential emphasis or strong emphasis spans with the same closing delimiter, the shorter one (the one that opens later) takes precedence. Thus, for{panels}, **foo **bar baz** is parsed as **foo <strong>bar baz</strong> rather than <strong>foo **bar baz</strong>.

  5. Inline code spans, links, images, and HTML tags group more tightly than emphasis. So, when there is a choice between an interpretation that contains one of these elements and one that does not, the former always wins. Thus, for{panels}, *[foo*](bar) is parsed as *<a href="bar">foo*</a> rather than as <em>[foo</em>](bar).

These rules can be illustrated through a series of{panels}s.

Rule 1:

foo bar .

foo bar

This is not emphasis, because the opening * is followed by whitespace, and hence not part of a [left-flanking delimiter run]:

a * foo bar* .

a * foo bar*

This is not emphasis, because the opening * is preceded by an alphanumeric and followed by punctuation, and hence not part of a [left-flanking delimiter run]:

a*“foo”* .

a*"foo"*

Unicode nonbreaking spaces count as whitespace, too:

* a * .

* a *

Intraword emphasis with * is permitted:

foobar .

foobar

5678 .

5678

Rule 2:

foo bar .

foo bar

This is not emphasis, because the opening _ is followed by whitespace:

_ foo bar_ .

_ foo bar_

This is not emphasis, because the opening _ is preceded by an alphanumeric and followed by punctuation:

a_“foo”_ .

a_"foo"_

Emphasis with _ is not allowed inside words:

foo_bar_ .

foo_bar_

5_6_78 .

5_6_78

пристаням_стремятся_ .

пристаням_стремятся_

Here _ does not generate emphasis, because the first delimiter run is right-flanking and the second left-flanking:

aa_“bb”_cc .

aa_"bb"_cc

This is emphasis, even though the opening delimiter is both left- and right-flanking, because it is preceded by punctuation:

foo-(bar) .

foo-(bar)

Rule 3:

This is not emphasis, because the closing delimiter does not match the opening delimiter:

_foo* .

_foo*

This is not emphasis, because the closing * is preceded by whitespace:

*foo bar * .

*foo bar *

A line ending also counts as whitespace:

*foo bar * .

*foo bar *

This is not emphasis, because the second * is preceded by punctuation and followed by an alphanumeric (hence it is not part of a [right-flanking delimiter run]:

*(*foo) .

*(*foo)

The point of this restriction is more easily appreciated with this{panels}:

(foo) .

(foo)

Intraword emphasis with * is allowed:

foobar .

foobar

Rule 4:

This is not emphasis, because the closing _ is preceded by whitespace:

_foo bar _ .

_foo bar _

This is not emphasis, because the second _ is preceded by punctuation and followed by an alphanumeric:

_(_foo) .

_(_foo)

This is emphasis within emphasis:

(foo) .

(foo)

Intraword emphasis is disallowed for _:

_foo_bar .

_foo_bar

_пристаням_стремятся .

_пристаням_стремятся

foo_bar_baz .

foo_bar_baz

This is emphasis, even though the closing delimiter is both left- and right-flanking, because it is followed by punctuation:

(bar). .

(bar).

Rule 5:

foo bar .

foo bar

This is not strong emphasis, because the opening delimiter is followed by whitespace:

** foo bar** .

** foo bar**

This is not strong emphasis, because the opening ** is preceded by an alphanumeric and followed by punctuation, and hence not part of a [left-flanking delimiter run]:

a**“foo”** .

a**"foo"**

Intraword strong emphasis with ** is permitted:

foobar .

foobar

Rule 6:

foo bar .

foo bar

This is not strong emphasis, because the opening delimiter is followed by whitespace:

__ foo bar__ .

__ foo bar__

A line ending counts as whitespace:

__ foo bar__ .

__ foo bar__

This is not strong emphasis, because the opening __ is preceded by an alphanumeric and followed by punctuation:

a__“foo”__ .

a__"foo"__

Intraword strong emphasis is forbidden with __:

foo__bar__ .

foo__bar__

5__6__78 .

5__6__78

пристаням__стремятся__ .

пристаням__стремятся__

foo, bar, baz .

foo, bar, baz

This is strong emphasis, even though the opening delimiter is both left- and right-flanking, because it is preceded by punctuation:

foo-(bar) .

foo-(bar)

Rule 7:

This is not strong emphasis, because the closing delimiter is preceded by whitespace:

**foo bar ** .

**foo bar **

(Nor can it be interpreted as an emphasized *foo bar *, because of Rule 11.)

This is not strong emphasis, because the second ** is preceded by punctuation and followed by an alphanumeric:

**(**foo) .

**(**foo)

The point of this restriction is more easily appreciated with these{panels}s:

(foo) .

(foo)

Gomphocarpus (Gomphocarpus physocarpus, syn. Asclepias physocarpa) .

Gomphocarpus (Gomphocarpus physocarpus, syn. Asclepias physocarpa)

foo “bar” foo .

foo "bar" foo

Intraword emphasis:

foobar .

foobar

Rule 8:

This is not strong emphasis, because the closing delimiter is preceded by whitespace:

__foo bar __ .

__foo bar __

This is not strong emphasis, because the second __ is preceded by punctuation and followed by an alphanumeric:

__(__foo) .

__(__foo)

The point of this restriction is more easily appreciated with this{panels}:

(foo) .

(foo)

Intraword strong emphasis is forbidden with __:

__foo__bar .

__foo__bar

__пристаням__стремятся .

__пристаням__стремятся

foo__bar__baz .

foo__bar__baz

This is strong emphasis, even though the closing delimiter is both left- and right-flanking, because it is followed by punctuation:

(bar). .

(bar).

Rule 9:

Any nonempty sequence of inline elements can be the contents of an emphasized span.

foo bar .

foo bar

foo bar .

foo bar

In particular, emphasis and strong emphasis can be nested inside emphasis:

foo bar baz .

foo bar baz

foo bar baz .

foo bar baz

foo bar .

foo bar

foo bar .

foo bar

foo bar baz .

foo bar baz

foobarbaz .

foobarbaz

Note that in the preceding case, the interpretation

<p><em>foo</em><em>bar<em></em>baz</em></p>

is precluded by the condition that a delimiter that can both open and close (like the * after foo) cannot form emphasis if the sum of the lengths of the delimiter runs containing the opening and closing delimiters is a multiple of 3 unless both lengths are multiples of 3.

For the same reason, we don’t get two consecutive emphasis sections in this{panels}:

foo**bar .

foo**bar

The same condition ensures that the following cases are all strong emphasis nested inside emphasis, even when the interior whitespace is omitted:

foo bar .

foo bar

foo bar .

foo bar

foobar .

foobar

When the lengths of the interior closing and opening delimiter runs are both multiples of 3, though, they can match to create emphasis:

foobarbaz .

foobarbaz

foobar***baz .

foobar***baz

Indefinite levels of nesting are possible:

foo bar baz bim bop .

foo bar baz bim bop

foo bar .

foo bar

There can be no empty emphasis or strong emphasis:

** is not an empty emphasis .

** is not an empty emphasis

**** is not an empty strong emphasis .

**** is not an empty strong emphasis

Rule 10:

Any nonempty sequence of inline elements can be the contents of an strongly emphasized span.

foo bar .

foo bar

foo bar .

foo bar

In particular, emphasis and strong emphasis can be nested inside strong emphasis:

foo bar baz .

foo bar baz

foo bar baz .

foo bar baz

foo bar .

foo bar

foo bar .

foo bar

foo bar baz .

foo bar baz

foobarbaz .

foobarbaz

foo bar .

foo bar

foo bar .

foo bar

Indefinite levels of nesting are possible:

foo bar baz bim bop .

foo bar baz bim bop

foo bar .

foo bar

There can be no empty emphasis or strong emphasis:

__ is not an empty emphasis .

__ is not an empty emphasis

____ is not an empty strong emphasis .

____ is not an empty strong emphasis

Rule 11:

foo *** .

foo ***

foo * .

foo *

foo _ .

foo _

foo ***** .

foo *****

foo * .

foo *

foo _ .

foo _

Note that when delimiters do not match evenly, Rule 11 determines that the excess literal * characters will appear outside of the emphasis, rather than inside it:

*foo .

*foo

foo* .

foo*

*foo .

*foo

***foo .

***foo

foo* .

foo*

foo*** .

foo***

Rule 12:

foo ___ .

foo ___

foo _ .

foo _

foo * .

foo *

foo _____ .

foo _____

foo _ .

foo _

foo * .

foo *

_foo .

_foo

Note that when delimiters do not match evenly, Rule 12 determines that the excess literal _ characters will appear outside of the emphasis, rather than inside it:

foo_ .

foo_

_foo .

_foo

___foo .

___foo

foo_ .

foo_

foo___ .

foo___

Rule 13 implies that if you want emphasis nested directly inside emphasis, you must use different delimiters:

foo .

foo

foo .

foo

foo .

foo

foo .

foo

However, strong emphasis within strong emphasis is possible without switching delimiters:

foo .

foo

foo .

foo

Rule 13 can be applied to arbitrarily long sequences of delimiters:

foo .

foo

Rule 14:

foo .

foo

foo .

foo

Rule 15:

foo _bar baz_ .

foo _bar baz_

foo bar *baz bim bam .

foo bar *baz bim bam

Rule 16:

**foo bar baz .

**foo bar baz

*foo bar baz .

*foo bar baz

Rule 17:

*bar* .

*bar*

_foo bar_ .

_foo bar_

*markdown/spec/foo .

*

** .

**

__ .

__

a * .

a *

a _ .

a _

**ahttp://foo.bar/?q=** .

**ahttp://foo.bar/?q=**

__ahttp://foo.bar/?q=__ .

__ahttp://foo.bar/?q=__

6.4. Images

Syntax for images is like the syntax for links, with one difference. Instead of [link text], we have an image description. The rules for this are the same as for [link text], except that (a) an image description starts with ![ rather than [, and (b) an image description may contain links. An image description has inline elements as its contents. When an image is rendered to HTML, this is standardly used as the image’s alt attribute.

![foo](/url "title")

<p><img src="/url" alt="foo" title="title" /></p>

![foo *bar*]

[foo *bar*]: train.jpg "train & tracks"

<p><img src="train.jpg" alt="foo bar" title="train &amp; tracks" /></p>

![foo ![bar](/url)](/url2)

<p><img src="/url2" alt="foo bar" /></p>

![foo [bar](/url)](/url2)

<p><img src="/url2" alt="foo bar" /></p>

Though this spec is concerned with parsing, not rendering, it is recommended that in rendering to HTML, only the plain string content of the [image description] be used. Note that in the above{panels}, the alt attribute’s value is foo bar, not foo [bar](/url) or foo <a href="/url">bar</a>. Only the plain string content is rendered, without formatting.

![foo *bar*][]

[foo *bar*]: train.jpg "train & tracks"

<p><img src="train.jpg" alt="foo bar" title="train &amp; tracks" /></p>

![foo *bar*][foobar]

[FOOBAR]: train.jpg "train & tracks"

<p><img src="train.jpg" alt="foo bar" title="train &amp; tracks" /></p>

![foo](train.jpg)

<p><img src="train.jpg" alt="foo" /></p>

My ![foo bar](/path/to/train.jpg  "title"   )

<p>My <img src="/path/to/train.jpg" alt="foo bar" title="title" /></p>

![foo](<url>)

<p><img src="url" alt="foo" /></p>

![](/url)

<p><img src="/url" alt="" /></p>

Reference-style:

![foo][bar]

[bar]: /url

<p><img src="/url" alt="foo" /></p>

![foo][bar]

[BAR]: /url

<p><img src="/url" alt="foo" /></p>

Collapsed:

![foo][]

[foo]: /url "title"

<p><img src="/url" alt="foo" title="title" /></p>

![*foo* bar][]

[*foo* bar]: /url "title"

<p><img src="/url" alt="foo bar" title="title" /></p>

The labels are case-insensitive:

![Foo][]

[foo]: /url "title"

<p><img src="/url" alt="Foo" title="title" /></p>

As with reference links, spaces, tabs, and line endings, are not allowed between the two sets of brackets:

![foo] 
[]

[foo]: /url "title"

<p><img src="/url" alt="foo" title="title" />
[]</p>

Shortcut:

![foo]

[foo]: /url "title"

<p><img src="/url" alt="foo" title="title" /></p>

![*foo* bar]

[*foo* bar]: /url "title"

<p><img src="/url" alt="foo bar" title="title" /></p>

Note that link labels cannot contain unescaped brackets:

![[foo]]

[[foo]]: /url "title"

<p>![[foo]]</p>
<p>[[foo]]: /url &quot;title&quot;</p>

The link labels are case-insensitive:

![Foo]

[foo]: /url "title"

<p><img src="/url" alt="Foo" title="title" /></p>

If you just want a literal ! followed by bracketed text, you can backslash-escape the opening [:

!\[foo]

[foo]: /url "title"

<p>![foo]</p>

If you want a link after a literal !, backslash-escape the !:

\![foo]

[foo]: /url "title"

<p>!<a href="/url" title="title">foo</a></p>

6.6. Raw HTML

Text between < and > that looks like an HTML tag is parsed as a raw HTML tag and will be rendered in HTML without escaping. Tag and attribute names are not limited to current HTML tags, so custom tags (and even, say, DocBook tags) may be used.

Here is the grammar for tags:

A tag name consists of an ASCII letter followed by zero or more ASCII letters, digits, or hyphens (-).

An attribute consists of spaces, tabs, and up to one line ending, an [attribute name], and an optional [attribute value specification].

An attribute name consists of an ASCII letter, _, or :, followed by zero or more ASCII letters, digits, _, ., :, or -. (Note: This is the XML specification restricted to ASCII. HTML5 is laxer.)

An attribute value specification consists of optional spaces, tabs, and up to one line ending, a = character, optional spaces, tabs, and up to one line ending, and an [attribute value].

An attribute value consists of an [unquoted attribute value], a [single-quoted attribute value], or a [double-quoted attribute value].

An unquoted attribute value is a nonempty string of characters not including spaces, tabs, line endings, ", ', =, <, >, or `.

A single-quoted attribute value consists of ', zero or more characters not including ', and a final '.

A double-quoted attribute value consists of ", zero or more characters not including ", and a final ".

An open tag consists of a < character, a [tag name], zero or more [attributes], optional spaces, tabs, and up to one line ending, an optional / character, and a > character.

A closing tag consists of the string </, a [tag name], optional spaces, tabs, and up to one line ending, and the character >.

An HTML comment consists of <!-- + text + -->, where text does not start with > or ->, does not end with -, and does not contain --. (See the HTML5 spec.)

A processing instruction consists of the string <?, a string of characters not including the string ?>, and the string ?>.

A declaration consists of the string <!, an ASCII letter, zero or more characters not including the character >, and the character >.

A CDATA section consists of the string <![CDATA[, a string of characters not including the string ]]>, and the string ]]>.

An HTML tag consists of an [open tag], a [closing tag], an [HTML comment], a [processing instruction], a [declaration], or a [CDATA section].

Here are some simple open tags:

<a><bab><c2c>

<p><a><bab><c2c></p>

Empty elements:

<a/><b2/>

<p><a/><b2/></p>

Whitespace is allowed:

<a  /><b2
data="foo" >

<p><a  /><b2
data="foo" ></p>

With attributes:

<a foo="bar" bam = 'baz <em>"</em>'
_boolean zoop:33=zoop:33 />

<p><a foo="bar" bam = 'baz <em>"</em>'
_boolean zoop:33=zoop:33 /></p>

Custom tag names can be used:

Foo <responsive-image src="foo.jpg" />

<p>Foo <responsive-image src="foo.jpg" /></p>

Illegal tag names, not parsed as HTML:

<33> <__>

<p>&lt;33&gt; &lt;__&gt;</p>

Illegal attribute names:

<a h*#ref="hi">

<p>&lt;a h*#ref=&quot;hi&quot;&gt;</p>

Illegal attribute values:

<a href="hi'> <a href=hi'>

<p>&lt;a href=&quot;hi'&gt; &lt;a href=hi'&gt;</p>

Illegal whitespace:

< a><
foo><bar/ >
<foo bar=baz
bim!bop />

<p>&lt; a&gt;&lt;
foo&gt;&lt;bar/ &gt;
&lt;foo bar=baz
bim!bop /&gt;</p>

Missing whitespace:

<a href='bar'title=title>

<p>&lt;a href='bar'title=title&gt;</p>

Closing tags:

</a></foo >

<p></a></foo ></p>

Illegal attributes in closing tag:

</a href="foo">

<p>&lt;/a href=&quot;foo&quot;&gt;</p>

Comments:

foo <!-- this is a
comment - with hyphen -->

<p>foo <!-- this is a
comment - with hyphen --></p>

foo <!-- not a comment -- two hyphens -->

<p>foo &lt;!-- not a comment -- two hyphens --&gt;</p>

Not comments:

foo <!--> foo -->

foo <!-- foo--->

<p>foo &lt;!--&gt; foo --&gt;</p>
<p>foo &lt;!-- foo---&gt;</p>

Processing instructions:

foo <?php echo $a; ?>

<p>foo <?php echo $a; ?></p>

Declarations:

foo <!ELEMENT br EMPTY>

<p>foo <!ELEMENT br EMPTY></p>

CDATA sections:

foo <![CDATA[>&<]]>

<p>foo <![CDATA[>&<]]></p>

Entity and numeric character references are preserved in HTML attributes:

foo <a href="&ouml;">

<p>foo <a href="&ouml;"></p>

Backslash escapes do not work in HTML attributes:

foo <a href="\*">

<p>foo <a href="\*"></p>

<a href="\"">

<p>&lt;a href=&quot;&quot;&quot;&gt;</p>

6.7. Hard line breaks

A line ending (not in a code span or HTML tag) that is preceded by two or more spaces and does not occur at the end of a block is parsed as a hard line break (rendered in HTML as a <br /> tag):

foo  
baz

<p>foo<br />
baz</p>

For a more visible alternative, a backslash before the [line ending] may be used instead of two or more spaces:

foo\
baz

<p>foo<br />
baz</p>

More than two spaces can be used:

foo       
baz

<p>foo<br />
baz</p>

Leading spaces at the beginning of the next line are ignored:

foo  
     bar

<p>foo<br />
bar</p>

foo\
     bar

<p>foo<br />
bar</p>

Hard line breaks can occur inside emphasis, links, and other constructs that allow inline content:

*foo  
bar*

<p><em>foo<br />
bar</em></p>

*foo\
bar*

<p><em>foo<br />
bar</em></p>

Hard line breaks do not occur inside code spans

`code  
span`

<p><code>code   span</code></p>

`code\
span`

<p><code>code\ span</code></p>

or HTML tags:

<a href="foo  
bar">

<p><a href="foo  
bar"></p>

<a href="foo\
bar">

<p><a href="foo\
bar"></p>

Hard line breaks are for separating inline content within a block. Neither syntax for hard line breaks works at the end of a paragraph or other block element:

foo\

<p>foo\</p>

foo  

<p>foo</p>

### foo\

<h3>foo\</h3>

### foo  

<h3>foo</h3>

6.8. Soft line breaks

A regular line ending (not in a code span or HTML tag) that is not preceded by two or more spaces or a backslash is parsed as a softbreak. (A soft line break may be rendered in HTML either as a [line ending] or as a space. The result will be the same in browsers. In the{panels}s here, a [line ending] will be used.)

foo
baz

<p>foo
baz</p>

Spaces at the end of the line and beginning of the next line are removed:

foo 
 baz

<p>foo
baz</p>

A conforming parser may render a soft line break in HTML either as a line ending or as a space.

A renderer may also provide an option to render soft line breaks as hard line breaks.

6.9. Textual content

Any characters not given an interpretation by the above rules will be parsed as plain textual content.

hello $.;'there

<p>hello $.;'there</p>

Foo χρῆν

<p>Foo χρῆν</p>

Internal spaces are preserved verbatim:

Multiple     spaces

<p>Multiple     spaces</p>

previous

5. 容器块

next

7. 附录

By xinetzone
© Copyright 2021, xinetzone.