Revised 2005 proposal for meta-data

[Michel Fortin]

Le 2006-12-29 à 7:53, Andrea Censi a écrit :


> This is the revised 2005 proposal for meta-data, much more in detail:

>

> http://maruku.rubyforge.org/proposal.md

> http://maruku.rubyforge.org/proposal.html

> http://maruku.rubyforge.org/proposal.pdf

>

> I wait for comments.



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

  - - -

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

  - - -

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

  - - -

"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, 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 `=`.

  - - -

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

I don't think so, not if we're mixing them with attribute references  
and magic shortcuts. I don't think this would be very readable:

     [link][1]{.class hreflang = fr ref}

     {ref}: lang = en .class

  - - -

"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

with this:

     [link][1]{.class hreflang=fr ref}

     {ref}: lang=en .class

I think the key/value association is clearer in the second example.


  - - -

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 think this problem is inexistent with the way block elements are  
parsed.


Michel Fortin
michel.fortin at michelf.com
http://www.michelf.com/