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
[EMAIL PROTECTED]
http://www.michelf.com/
_______________________________________________
Markdown-Discuss mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/markdown-discuss
