Revised 2005 proposal for meta-data

[Michel Fortin]

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.


Exact.


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

> "reference to an attribute list"?


Exact.


> and this:

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

> is a "definition of an attribute list"?


Exact.


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

>

> http://www.w3.org/TR/html401/types.html#type-name

>

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

>

>  http://www.w3.org/TR/xml/#NT-Name

>

> this is indeed more liberal.


And the WHATWG's HTML5-wannabe draft specification does not put any  
restriction on the value of id. <http://www.whatwg.org/specs/web-apps/ 
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 michelf.com
http://www.michelf.com/