Revised 2005 proposal for meta-data

Andrea Censi andrea at
Sat Dec 30 11:48:44 EST 2006

> {#myid .class1 .class2}

> {id=myid class=class1 class=class2}

> {id=myid class="class1 class2"}


> In my current implementation, the first and the last one are

> equivalent, but not the one in the middle: the second class will

> override the first one. I think it's more coherent to reserve the

> magic to the ".class" syntax. And overriding may also be a useful

> feature in some circumstances where you have a remotely-defined class

> you want to replace completly:


> ## 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.

> "tags"


> Why not "attribute definitions" and "attribute references" in the

> same spirit as link definitions and link references? "Tag" makes me

> think of HTML tags.

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"?

> "An unquoted value must not start with a double quote, and may

> contain everything except whitespace"


> You need an exception for the closing brace when the attribute is

> defined inline, and I would allow attribute values to be enclosed in

> single quotes too, just like HTML and XML permits it.

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 \'.

> "Identifiers must begin with a letter ([A-Za-z]) and may be followed

> by any number of letters, digits ([0-9]), hyphens (-), underscores

> (_), colons (:), and periods (.)."


> This seems too restrictive. First, id and class in HTML and XML both

> allow much more Unicode characters,

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 second: what should happen

> when someone introduce an invalid character somewhere? Do we pass it

> unmodified, try to correct it, or skip it completely? I'd go with the

> former, except for the cases where it would destroy the markup like

> having an attribute name with `>` or `=`.

I don't have a clear idea about this.

> "Question: should we allow whitespace at the sides of = in key/value

> pairs?"


> I don't think so,

OK, let's make it easy to parse.

> "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

> - - -


> 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 \]\[\`"}

I wait 2/3 days for other comments (J-G?) then procede to revise the draft.

Andrea Censi
"Life is too important to be taken seriously" (Oscar Wilde)

More information about the Markdown-Discuss mailing list