> I also agree with your opposition to them; if anything, one
> should filter the *output* of a Markdown-to-HTML conversion
> so that it won't matter whether people write literal ``
> tags or use asterisks.
This is true in theory... I actually just recently write something
along those lines in Lu
* Michel Fortin <[EMAIL PROTECTED]> [2008-05-23 04:35]:
> I'm not sure those "features" should be formally part of the
> spec. I believe however that if the spec is well written it
> should be pretty trivial to see what must be changed to achieve
> them.
Yeah, I don’t think they belong in the spec
Le 2008-05-16 à 0:31, Yuri Takhteyev a écrit :
Your first two examples are not treated as the same by any
implementation. It seems that all implementations interprete this:
~~~
One
Two
Three
Four
Five
~~~
as meaning that "One" is in a code block, but "Two" is not.
Or did yo
Le 2008-05-22 à 2:10, Aristotle Pagaltzis a écrit :
It is, mind, perfectly fine to have two (or maybe three?) specs
of which one is a superset of the other, as seems to be Michel’s
current thrust with Markdown vs Markdown Extra. Assuming that no
feature in either spec is optional, that means you
On 22 May 2008, at 08:10, Aristotle Pagaltzis wrote:
[...]
Optional features are dangerous and impede interoperability.
Everyone who ever thinks about chipping in on the design of
a spec should read [section 5 of RFC 3339][1]. [...]
I love how it says:
[...] A format which includes rarel
