Re: Markdown Extra Spec: Parsing Section

[John MacFarlane]

> If we're going this way, there's going to be a learning curve: for
> me, and for everyone trying to understand the syntax. I'd prefer to
> avoid forcing people to learn a new language only to understand the
> specification.

PS. Here's all you have to learn in order to write or read a PEG grammar.

A B C A followed by B followed by C
A | B A or B (ordered choice)
A+one or more As
A*zero or more As
A?optional A
!Anot followed by A
&Afollowed by A (but does not consume A)
(A B) grouping
. matches any character
'x'   matches the character 'x'
"string"  matches the string "string"
[a-z] matches a character from 'a' to 'z'

English could be used to specify how a semantic value is to be
constructed for each matching rule. This part would be implemented
differently in different languages, but the basic PEG grammar would be
the same.

John

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[John MacFarlane]

+++ Michel Fortin [May 13 08 00:32 ]:
> Le 2008-05-12 à 18:14, John MacFarlane a écrit :
>
>> The PEG representation is concise, precise, and readable.
>
> Readable, hum... if I look at this rule from PEG Markdown:
>
>   ListContinuationBlock = a:StartList
>   ( BlankLines
>   { if (strlen($$.contents.str) == 0)
>   $$.contents.str = strdup("\001"); /* block separator */
>   pushelt($$, &a); } )
>   ( Indent ListBlock { pushelt($$, &a); } )+
>   { $$ = mk_str(concat_string_list(reverse(a.children))); }
>
> it looks a lot like code to me, half of it I don't understand. 

Well, you've picked the ugliest part.  But don't be repelled too
quickly. Note that the stuff between { } is C code that constructs the
syntax tree. If you just want to see the syntax specification, you can
pretty much ignore those parts. The "StartList" bit can also be ignored,
as it just initializes a list. With that stripped out, you get:

ListContinuationBlock = Blanklines (Indent ListBlock)+

That is, a list continuation block is some blank lines followed by
one or more ListBlocks, each preceded by indentation.  That seems
pretty readable to me.

Here's the part that concerns the recent discussion about "refname"
(again, I've omitted the {} parts and parts that modify the rules
depending on which syntax extensions have been selected).

Reference = NonindentSpace Label ':' Spnl RefSrc Spnl RefTitle
BlankLine*

A reference is some space of less than one indent, followed by a
Label, followed by ':', followed by optional blank space including
at most one newline, followed by a RefSrc, followed
by optional blank space including at most one newline, followed by
a RefTitle, followed by optional blanklines.  (You may not agree
with that.  But it's easy to see how to modify the rule above if,
for example, you don't think leading space should be allowed.)
 
Label = '[' (!']' Inline)+ ']'

A label is a '[' followed by a string of one or more Inline elements
that don't begin with ']', followed by ']'.  (Note: this allows
text within balanced brackets, which will be parsed as a single Inline
element.)

RefSrc = Nonspacechar+ 

A RefSrc is a string of one or more nonspace characters.

And so on.

Again, a lot of the ugliness of the specification is due to the C
code that constructs the parse tree. If that bothers you, you might
like the Haskell version better (though there are a few problems with
that grammar that I have corrected in the C version).  It contains
a minimum of embedded code, and the whole grammar fits in just 
160 lines:

http://github.com/jgm/markdown-peg/tree/4438c336444a714f15ed619c9897d91c3ab6b40e/Markdown.hs#L68

I've been working on the C version mainly because more people have
access to a C compiler, and because it's significantly faster than the
Haskell.

John

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[John MacFarlane]

+++ Michel Fortin [May 13 08 00:18 ]:
>> Is there any good reason for having two different types here?
>
> The link text can contain other span-level elements, such as emphasis,  
> code blocks, etc. This *has* to be taken into account while parsing. On 
> the other hand, text in the reference part is just plain text.

But it needn't be.  Both constructs could be parsed as sequences of
inline elements.  That's how pandoc and peg-markdown treat them.

John

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[Jacob Rus]

Michel Fortin wrote:

Le 2008-05-12 à 18:14, John MacFarlane a écrit :


The PEG representation is concise, precise, and readable.


Readable, hum... if I look at this rule from PEG Markdown:

ListContinuationBlock = a:StartList
( BlankLines
{ if (strlen($$.contents.str) == 0)
$$.contents.str = strdup("\001"); /* block separator */
pushelt($$, &a); } )
( Indent ListBlock { pushelt($$, &a); } )+
{ $$ = mk_str(concat_string_list(reverse(a.children))); }

it looks a lot like code to me, half of it I don't understand. If we're 
going this way, there's going to be a learning curve: for me, and for 
everyone trying to understand the syntax. I'd prefer to avoid forcing 
people to learn a new language only to understand the specification.


Yeah, that's worse.

Mainly I just would suggest taking all those numbered lists of things, 
and putting them on a single line.  It's not that it has to be BNF or 
EBNF/ABNF/whatever, but parts which *can* be expressed in such a way, 
and can be condensed to fit in a more compact space, should be.  The 
current numbered lists + English approach, in many parts of your current 
work, just add visual clutter. :)


-Jacob

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[Jacob Rus]

Michel Fortin wrote:
Anyway, with the parsing model in three passes I'm currently defining 
it's pretty trivial to do correctly: the block elements pass extracts 
the text of the blockquote, leaving this to parse by the span element pass:


what about this  case?

The span element pass would then see an autolink and just ignore any 
newline it finds in the URL.


Ah, okay.  Somehow I misread that.  Yes, that seems about right.

-Jacob

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[Michel Fortin]

Le 2008-05-12 à 18:14, John MacFarlane a écrit :


The PEG representation is concise, precise, and readable.


Readable, hum... if I look at this rule from PEG Markdown:

ListContinuationBlock = a:StartList
( BlankLines
{ if (strlen($$.contents.str) == 0)
$$.contents.str = strdup("\001"); /* block separator */
pushelt($$, &a); } )
( Indent ListBlock { pushelt($$, &a); } )+
{ $$ = mk_str(concat_string_list(reverse(a.children))); }

it looks a lot like code to me, half of it I don't understand. If  
we're going this way, there's going to be a learning curve: for me,  
and for everyone trying to understand the syntax. I'd prefer to avoid  
forcing people to learn a new language only to understand the  
specification.



Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[Michel Fortin]

Le 2008-05-12 à 21:55, John MacFarlane a écrit :


I am assuming that there will be a different type to deal with link
text.


There will.


Is there any good reason for having two different types here?


The link text can contain other span-level elements, such as emphasis,  
code blocks, etc. This *has* to be taken into account while parsing.  
On the other hand, text in the reference part is just plain text.




As far as
I can see, allowing anything that can serve as link text to be a  
refname

would not contradict anything in the official Markdown syntax
specification. In addition, it is hard to imagine a realistic case  
where

allowing brackets and newlines in refnames would break an existing
document. Why make users remember extra restrictions? (I didn't even
know about them until a few days ago, and I've used markdown for  
years.)
And why expose users to the risk that their documents will break if  
they

hard-wrap a long refname?


I'm in favor of allowing hard-wrapped reference names where the line  
break is not significant, so that will probably end up in the spec  
when I write the part about parsing the link span element.


Please keep in mind that the current refname construct is for the  
reference name in link definitions, and may be different from the one  
used in the link span element.




I think the current behavior of phpmarkdown and Markdown.pl is very
confusing. This produces a link:

   [[hi]][]

   [[hi]]: /url

But this doesn't produce a link:

   [hello][[hi]]

   [[hi]]: /url

So either (a) not all link references begin with a refname, or (b)
refnames can sometimes (but not always!) contain embedded brackets.
Either option would conflict with Michel's syntax specification
as it now stands.



This situation is indeed inconsistant. I'd be in favor of allowing  
balanced square brakets in link reference, even though John Gruber  
seems (or seemed in 2006) to think they should be disallowed completely.




Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Michel Fortin]

Le 2008-05-12 à 9:02, Waylan Limberg a écrit :


I'm currently thinking of allowing the following, which I find more
appealing visually:

   ~~ .html
   Hello World!
   ~~



Actually, I had done it that way first. Then I went back and reviewed
the previous discussions. Interestingly, I had originally made the
case for having the label on the top, rather than the bottom. But
after further thinking, I realized that my current implementation is
consistent with the HeaderID syntax.


More or less. The header id syntax always puts the id value on the  
first line. :-)



Given the number of complaints we've been getting on the list  
recently about styling inconsistencies in the syntax, I figured that  
made for a stronger argument so I used curly brackets at the end. If  
the consensus is on something different, I can work with it.



If I'm not mistaken, most of the complains are about the  
inconsistencies between different implementations of the syntax,  
resulting, at least in part, of the lack of a precise and unambiguous  
grammar.


In the example above, I try to think of the ".html" as a file  
extension indicating the format of the code snippet and that using it  
as a class name in the HTML representation is just coincidental. I  
think it feels very natural that way.


I wouldn't recommend doing class names outside curly brakets in  
general. Only here, it fits pretty nicely.


What do other people think?


Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[John MacFarlane]

>> I am assuming that there will be a different type to deal with link  
>> text.
>
> There will.

Is there any good reason for having two different types here? As far as
I can see, allowing anything that can serve as link text to be a refname
would not contradict anything in the official Markdown syntax
specification. In addition, it is hard to imagine a realistic case where
allowing brackets and newlines in refnames would break an existing
document. Why make users remember extra restrictions? (I didn't even
know about them until a few days ago, and I've used markdown for years.)
And why expose users to the risk that their documents will break if they
hard-wrap a long refname?

I think the current behavior of phpmarkdown and Markdown.pl is very
confusing. This produces a link:

[[hi]][]

[[hi]]: /url

But this doesn't produce a link:

[hello][[hi]]

[[hi]]: /url

So either (a) not all link references begin with a refname, or (b)
refnames can sometimes (but not always!) contain embedded brackets.
Either option would conflict with Michel's syntax specification
as it now stands.

John
 
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Már Örlygsson]

Waylan Limberg wrote:
> I had initially intended on doing that myself. However, I figured
> support for Highlight.js would be more important.

Placing the class-name on the outer element gives more styling flexibility.
I'd like to think Markdown will be around much longer than highlight.js.
Also: libraries change, gain features, etc...


-- 
Már
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Markdown Extra Spec: Parsing Section

[John MacFarlane]

+++ Michel Fortin [May 11 08 22:26 ]:
> Le 2008-05-11 à 20:55, Jacob Rus a écrit :
>
>> You should write it in something closer to a BNF-like format.  The  
>> current version is about 10x more verbose than necessary, and it makes 
>> reading the spec considerably more difficult.
>
> The reason I'm doing it like this is that I doubt everything will be  
> expressible in a BNF format.

You can come pretty close with a PEG grammar:
http://github.com/jgm/peg-markdown/tree/master/markdown_parser.leg#L236

I have implemented the basic markdown syntax + the footnote syntax from
PHP markdown extra, and so far I've found only two things that can't be
cleanly expressed using a PEG:

1. Indented block contexts like lists and blockquotes. Here I use a
multi-pass approach. The first pass takes, say, a list item

1.  my list item

- with
- nested list

and returns a listitem with "raw" contents

my list item

- with
- nested list

which are piped through the markdown parser again.

2.  Inline code.  PEG can't express "a row of backticks, followed
by a string of characters not containing an equally long row of
backticks, followed by an equally long row of backticks."
It can express, for particular values of N, "a row of N backticks,
followed by a string of characters not containing a row of N
backticks, followed by a row of N backticks."  So if you have
a fixed limit on the number of backticks that can start a stretch
of inline code, you're okay.  peg-markdown sets this limit at 5,
which should be enough for most purposes.  But one could set it
higher without much of a performance penalty.

The PEG representation is concise, precise, and readable.
But the big advantage is that it can be converted automatically into a
fast parser. This means that you can be sure that your markdown program
really does implement the formal specification. An informal English
specification won't give you that.

John

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: PHP Markdown 1.0.1l & Extra 1.2

[John MacFarlane]

The development version of pandoc has for some time 
implemented "fenced" code blocks.  See
http://code.google.com/p/pandoc/source/browse/trunk/README#717
for documentation.  Two small differences with your syntax:

1.  pandoc allows the block to be ended by a line of tildes
of the same length as *or longer than* the start line.
Reason:  It's easy to produce a longer line by just eyeballing
it, whereas to produce a line of exactly the same length,
you generally need to cut and paste.  I'm following the
general markdown philosophy of allowing slop when it's harmless.

2.  pandoc allows { .haskell .number-lines } (or whatever) after
the *top* line of tildes.  If pandoc is compiled with highlighting
support, it uses this information to highlight the block; otherwise,
it just includes it as a class.

Thanks for pointing out the complexity involving leading blank lines
in code blocks; I'll make a note to fix that.

If anyone wants to try pandoc with the delimited ("fenced") code blocks and
built-in syntax highlighting, see
http://groups.google.com/group/pandoc-discuss/browse_thread/thread/b59714fcfc7a7e69
for instructions.

John

+++ Michel Fortin [May 11 08 08:31 ]:
> Time for an update to PHP Markdown and PHP Markdown Extra.
>
> 
>
> This new version of PHP Markdown Extra adds support for "fenced" code  
> blocks (which I was previously calling "flat"). Fenced code blocks  
> overcome many limitations of Markdown's indented code blocks: they can  
> can be put immediately following a list item, can start and end with  
> blank lines, and can be put one after the other as two consecutive code 
> blocks. Also, if you're using an editor which cannot indent  
> automatically a selected block of text, such as a text box in your web  
> browser, it's easier to paste code in.
>
> 
>
>
> 1.0.1l (11 May 2008):
>
> * Now removing the UTF-8 BOM at the start of a document, if present.
>
> * Now accepting capitalized URI schemes (such as HTTP:) in automatic
>   links, such as ``.
>
> * Fixed a problem where `<[EMAIL PROTECTED]>` was seen as a horizontal
>   rule instead of an automatic link.
>
> * Fixed an issue where some characters in Markdown-generated HTML
>   attributes weren't properly escaped with entities.
>
> * Fix for code blocks as first element of a list item. Previously,
>   this didn't create any code block for item 2:
>   
>   *   Item 1 (regular paragraph)
>   
>   *   Item 2 (code block)
>
> * A code block starting on the second line of a document wasn't seen
>   as a code block. This has been fixed.
>   
> * Added programatically-settable parser properties `predef_urls` and
>   `predef_titles` for predefined URLs and titles for reference-style
>   links. To use this, your PHP code must call the parser this way:
>   
>   $parser = new Markdwon_Parser;
>   $parser->predef_urls = array('linkref' => 'http://example.com');
>   $html = $parser->transform($text);
>   
>   You can then use the URL as a normal link reference:
>   
>   [my link][linkref]  
>   [my link][linkRef]
>   
>   Reference names in the parser properties *must* be lowercase.
>   Reference names in the Markdown source may have any case.
>
> * Added `setup` and `teardown` methods which can be used by subclassers
>   as hook points to arrange the state of some parser variables before and
>   after parsing.
>
>
> Extra 1.2 (11 May 2008):
>
> * Added fenced code block syntax which don't require indentation
>   and can start and end with blank lines. A fenced code block
>   starts with a line of consecutive tilde (~) and ends on the
>   next line with the same number of consecutive tilde. Here's an
>   example:
>   
>   
>   Hello World!
>   
>
> * Rewrote parts of the HTML block parser to better accomodate
>   fenced code blocks.
>
> * Footnotes may now be referenced from within another footnote.
>
> * Added programatically-settable parser property `predef_attr` for
>   predefined attribute definitions.
>
> * Fixed an issue where an indented code block preceded by a blank
>   line containing some other whitespace would confuse the HTML
>   block parser into creating an HTML block when it should have
>   been code.
>
>
> Michel Fortin
> [EMAIL PROTECTED]
> http://michelf.com/
>
>
> ___
> Markdown-Discuss mailing list
> Markdown-Discuss@six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net

Re: Fenced-Code-Blocks in Python-Markdown

[Thomas Nichols]

Waylan Limberg wrote on 2008/05/12 14:02:

On Mon, May 12, 2008 at 7:16 AM, Michel Fortin
<[EMAIL PROTECTED]> wrote:
  


[snip]


 While it has been suggested some time ago that {.class-name} stand for a
class attribute applied to an arbitrary element, I'm wondering if we can't
do something better than that for code blocks.

 I'm currently thinking of allowing the following, which I find more
appealing visually:

~~ .html
Hello World!
~~




Actually, I had done it that way first. Then I went back and reviewed
the previous discussions. Interestingly, I had originally made the
case for having the label on the top, rather than the bottom. But
after further thinking, I realized that my current implementation is
consistent with the HeaderID syntax. Given the number of complaints
we've been getting on the list recently about styling inconsistencies
in the syntax, I figured that made for a stronger argument so I used
curly brackets at the end. If the consensus is on something different,
I can work with it.


  
Styling consistency  is surely a boon, but having the open-fence and 
close-fence markers indistinguishable seems problematic, as per

http://six.pairlist.net/pipermail/markdown-discuss/2007-December/000899.html

An attribute list  could be used to make this distinction, though it 
doesn't seem a strikingly elegant solution. Perhaps any text immediately 
following the  that is _not_ an attribute list (i.e. has no 
{braces}) could be silently ignored? This would allow


 begin
$eix app-misc/anki
[I] app-misc/anki [1]
Homepage:http://ichi2.net/anki/
Description: Anki - a friendly, intelligent spaced learning 
system.



The closing fence could optionally have `{.html}` appended.

Or would ignoring any non-braced content after the  cause other 
problems?


-- Thomas

___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Waylan Limberg]

On Mon, May 12, 2008 at 7:16 AM, Michel Fortin
<[EMAIL PROTECTED]> wrote:
> Le 2008-05-12 à 1:01, Waylan Limberg a écrit :
>
>
>
> > I'd like to announce a beta release of the Fenced-Code-Blocks
> > Extension for Python-Markdown.
> >
> > 
> >
>
>  Wow, that was fast! :-)

Thanks. Python-Markdown's extension API made is easy. Wasn't much more
than getting the regex put together (due to differences in regex
implementations, I couldn't just copy your PHP regex).

>
>  There is one particularity in my implementation I think you've missed
> though (which is not surprising given I haven't mentioned it anywhere, yet).
> It touches the output when there are leading blank lines.

Actually, I did see that in testing your implementation, but wasn't
sure exactly why you were doing it. I meant to come back to it later
and forgot about it. Shouldn't be to hard to add though. Your notes
will no doubt be helpful.

[snip]
>
>  While it has been suggested some time ago that {.class-name} stand for a
> class attribute applied to an arbitrary element, I'm wondering if we can't
> do something better than that for code blocks.
>
>  I'm currently thinking of allowing the following, which I find more
> appealing visually:
>
> ~~ .html
> Hello World!
> ~~
>

Actually, I had done it that way first. Then I went back and reviewed
the previous discussions. Interestingly, I had originally made the
case for having the label on the top, rather than the bottom. But
after further thinking, I realized that my current implementation is
consistent with the HeaderID syntax. Given the number of complaints
we've been getting on the list recently about styling inconsistencies
in the syntax, I figured that made for a stronger argument so I used
curly brackets at the end. If the consensus is on something different,
I can work with it.



-- 

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Waylan Limberg]

On Mon, May 12, 2008 at 6:58 AM, Már Örlygsson <[EMAIL PROTECTED]> wrote:
> >
Hello World!
>  >
>
>  It would be a much better idea to place the class-name on the outer
>  element  (``)
>
>
I had initially intended on doing that myself. However, I figured
support for Highlight.js would be more important. Besides, while I
generally like styling hooks on the outermost level in html, I can't
imagine any benefit in this scenario. And when you think about it, it
is the "code" that determines the styling, so logically the "code" tag
should get the styling hook. I suspect that was the reasoning behind
Highligh.js.



-- 

Waylan Limberg
[EMAIL PROTECTED]
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Michel Fortin]

Le 2008-05-12 à 1:01, Waylan Limberg a écrit :


I'd like to announce a beta release of the Fenced-Code-Blocks
Extension for Python-Markdown.




Wow, that was fast! :-)

There is one particularity in my implementation I think you've missed  
though (which is not surprising given I haven't mentioned it anywhere,  
yet). It touches the output when there are leading blank lines.


If you try this in various browsers:


a


You'll notice, when serving the file as text/html, that the first  
newline is lost. When parsing the file as XML, it stays there however.  
If you then add:



a


you'll then notice that the first line is there in Gecko, but still  
lost with Web Kit. So basically, you can't just add newlines at the  
start of a code block and expect it to work.


PHP Markdown Extra's output when you have a leading newline is as such:

a


which solves the situation in both Safari and Gecko-based browsers  
(haven't tested in others). If you have two leading newlines, then  
you'll get two s, etc.




The same syntax is used as the just released PHP Markdown Extra 1.2. I
did add the option to define a class on the block for language
identification. Here's an example:

   
   Hello World!
   {.html}

Becomes:

   
Hello World!
   


While it has been suggested some time ago that {.class-name} stand for  
a class attribute applied to an arbitrary element, I'm wondering if we  
can't do something better than that for code blocks.


I'm currently thinking of allowing the following, which I find more  
appealing visually:


~~ .html
Hello World!
~~



Unfortunately, including the class
definition makes PHP Markdown Extra fail to match the block. Consider
yourself warned.


Indeed.


Michel Fortin
[EMAIL PROTECTED]
http://michelf.com/


___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Re: Fenced-Code-Blocks in Python-Markdown

[Már Örlygsson]

>
Hello World!
>

It would be a much better idea to place the class-name on the outer
element  (``)


-- 
Már
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss