Revised 2005 proposal for meta-data

Michel Fortin michel.fortin at
Sat Dec 30 23:04:22 EST 2006

Le 2006-12-30 à 11:48, Andrea Censi a écrit :

>> ## Header ## {boo class="override"}


>> {boo}: .boo style=color:green;font-weight:bold


> Seems reasonable. So the special case is: ".class1" adds "class1" to

> the class attribute.


> OK - I didn't like "tag". So formally "boo" in the example is a

> "reference to an attribute list"?


> and this:

>> {boo}: .boo style=color:green;font-weight:bold

> is a "definition of an attribute list"?


> OK for the single quote.


> New version:


> An unquoted value must not start with a double quote or single

> quote, and may

> contain everything except whitespace and closing brace.


> Inside quote values, single and double quotes can be escaped by

> \" and \'.

Seems fine, although the closing brace could still be allowed for
attribute list definitions as those are terminated by the end of line
instead of braces.

> Actually, that's the exact HTML specification for the content of the

> ID attribute:




> This is the XML specification for the name of the attributes:




> this is indeed more liberal.

And the WHATWG's HTML5-wannabe draft specification does not put any
restriction on the value of id. <
current-work/#the-id> (Warning: huge document beyond this link)

But all this is beside the point: anyone wishing to add an invalid
attribute can do it by other means -- like {id="!R%)$#(XC +"} or by
writing directly inline HTML. Markdown (the syntax) isn't an HTML
sanitizer nor a validator; if the author wants to add an invalid
attribute we should let him do so.

>> "Question: should : be a synonym for = in attributes list."


>> While it would certainly be nice, I think it's a better idea to have

>> an HTML-like syntax to define HTML attributes. Beside, it's not very

>> clear what will happen when you have a space after the colon. Compare

>> this:


>> [link][1]{.class hreflang: fr ref}


>> {ref}: lang: en .class


> It's not ambiguous, but let's drop it. Another very good reason is

> that ":" indicates an xml namespace:


> {ref}: lang=en xml:lang=en

It's not ambiguous to the parser, but it is to the reader in my
opinion. I hadn't thought of XML namespace prefixes, but indeed
that's an interesting problem too.

>> Other considerations: allowing arbitrary attribute values on span

>> elements may pose problem to the current parsers. For instance, this

>> link:


>> [test][1]{title="`coco`"}


>> is hard to parse correctly, because if the link reference [1] is not

>> defined, the link becomes pure text and `coco` must be changed to a

>> code span, while if the link is defined then `coco` is an attribute

>> and must not be changed to a code span. The only way to get this

>> correctly is to parse all the span expressions together, creating a

>> "real" parser as some have suggested.


> I see two solutions:

> 1) in inline attribute list, we pose some limits on the characters

> you can use

> 2) Markdown special chars must be escaped also inside attributes

> lists, so that

>> [test][1]{title="`Quake ][`"}

> must be written:

>> [test][1]{title="\`Quake \]\[\`"}

That would work, but it's very inelegant. Oh, and escaping ][ isn't
really necessary. My current implementation -- which does nothing
special to solve this problem -- parse the thing perfectly when I
escape only the backticks.

Michel Fortin
michel.fortin at

More information about the Markdown-Discuss mailing list