* Yuri Takhteyev [EMAIL PROTECTED] [2008-03-03 02:20]:
What about setting value on each li instead?
Equally deprecated.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
___
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
Le 2008-03-02 à 21:47, John MacFarlane a écrit :
Nice job! You've got the speed record by a mile!
I've played with your program a bit, and so far it does well on most
of the
edge cases that cause problems for Markdown.pl. But, like Markdown.pl,
it generates invalid XHTML for this case:
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-03-03 07:00]:
i would prefer that implementers get more sophisticated
about teasing out the user's intent in ambiguous cases.
If every implementor teases a different intent out the same
document, the user loses.
Is it possible for everyone to agree
Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
What about setting value on each li instead?
Equally deprecated.
The HTML spec authors have admitted that they believe this particular
change was a mistake on their behalf.
All browsers support the value attribute on ol lis, and there are
Le 2008-03-03 à 0:55, [EMAIL PROTECTED] a écrit :
a specification will _eventually_ be used, by someone,
to tell the user they are doing things wrong, won't it?
Well, that's not the specification I intend to do. All inputs are
right in Markdown; there is no such thing as invalid or non-
Le 2008-03-02 à 19:49, Aristotle Pagaltzis a écrit :
This is actually my second biggest complaint with Markdown. As I
understand, John was originally going to allow numbered lists to
start at numbers other than 1, but then discovered that the HTML4
WG labelled the `start` attribute of lists
Allan Odgaard wrote:
Though without changing a lot of edge-case behavior, I find it hard
to see Markdown using such rule-based implementation, so personally
I am favoring a new Markdown-inspired language.
For my part, I'm currently trying to specify parsing rules Markdown
Extra, and make
Le 2008-03-03 à 6:36, Aristotle Pagaltzis a écrit :
Why then does the fallacious argument that a spec would represent
a loss for the user continue?
Some people have proposed before that some constructs may not be
outlawed, that syntax rules should be changed, that Markdown is either
too
I agree with all this. Pandoc's extended markdown syntax supports both
these features (with some heuristics to avoid capturing initials in
names). http://johnmacfarlane.net/pandoc/README.html#lists
John
The HTML spec authors have admitted that they believe this particular
change was a mistake
In article [EMAIL PROTECTED],
John MacFarlane markdown-discuss@six.pairlist.net wrote:
Nice job! You've got the speed record by a mile!
I've played with your program a bit, and so far it does well on most of the
edge cases that cause problems for Markdown.pl. But, like Markdown.pl,
it generates
On 29 Feb 2008, at 19:29, Yuri Takhteyev wrote:
Text::Markdown *does not* extend the original Markdown syntax *in
any
way*.
Well, I don't know if agree with this reading.
Good! My original comments were somewhat deliberately inflamatory to
try and provoke discussion - which seems to
well, i had said i wouldn't reply on this, but i think that
this post will still manage to be productive. i hope so...
***
aristotle said:
If every implementor teases a different intent
out the same document, the user loses.
well, yes. but that's pretty obvious, isn't it?
there
In article [EMAIL PROTECTED],
markdown-discuss@six.pairlist.net wrote:
however, implementers can reach agreement easily,
by leaving users out in the cold, brushing them off
with a you will need to follow the spec which seems
-- if i understand markdown's cornerstone correctly --
to be outside
On 3 Mar 2008, at 13:30, Michel Fortin wrote:
[...]
1. A regexp that makes the parser enter the context the rule
represents (e.g. block quote, list, raw, etc.).
2. A list of which rules are allowed in the context of this rule.
3. A regexp for leaving the context of this rule.
4. A regexp
14 matches
Mail list logo
