Proposed table specification (long!)
Bowerbird at aol.com
Bowerbird at aol.com
Wed May 18 13:21:40 EDT 2011
slept on this, but decided to send anyway, make it a trilogy...
> Well, then why don't you do it?
i've got some other fish to fry right now, in my own project,
but i will get around to tables soon enough with that myself,
and i'll be very happy to show people the results when i do...
and here are some of the "challenges" i'll want to try to handle:
> with all due respect, it's more than a little arrogant for
> anyone to insist that they got it perfect the first time (1.0.1).
well, gruber is well-known for being arrogant, but i do believe
that he has never insisted, or even claimed, he got it all "perfect".
and besides, the current charge is _neglect_, and not _arrogance_.
but all of that is a dodge as well. gruber isn't really the factor here.
the _real_ problem is that there's several different implementations,
and they differ between each other, and none of 'em is significantly
better than the others, so none of them can overcome the stalemate.
i repeat: it has nothing to do with gruber. nothing at all. really.
the only thing gruber could do is bless a successor. and he won't.
> The idea of Markdown, not the implementation, is what's special.
nope. lots of other people had "the idea" long before gruber.
indeed, "structured text" -- from which "restructured text" was
derived -- dates back to the 1990s, and was a contender against
the likes of .sgml. if tim berners-lee would have been smarter,
he woulda chosen light-markup instead of going the other way.
but he had the notion that he wanted to follow ted nelson, so he
went for the "hypertext" model instead, and botched everything,
including all of the brilliant things that nelson _actually_ meant...
gruber gets the markdown attention because gruber gets attention.
but if all of you implementers got yourselves _around_ a table and
decided to develop "markaround" to go _around_ gruber, you could.
if you all agreed, amongst yourselves, gruber doesn't have enough
power -- or programming chops, or fame -- to thwart all of you...
the question is whether you'd rather be big fish in your own ponds,
in the backchannels of the lake of gruber, or go swim in the ocean.
of course, pandoc might just sweep you all into the ocean anyway...
and once again, none of this is a dig. i haven't shared my own z.m.l.
with the world because i want to retain control over it, so that _my_
implementation is the _only_ one, so it is canonical, and therefore
there is absolutely no confusion about what the whole thing means.
with markdown, though, you do not have the luxury of such clarity...
> What we really need is an effort in the style of HTML5's HTML
> parsing algorithm which provides an unambiguous definition
> of how things should be parsed.
> Heck, I started one a while ago for Markdown Extra
> Then I stopped because I realized it'd be too long and that I had
> many more interesting projects I could do in that free time.
the other thing is that you were doing the task as the lead actor...
this effort will only work if it's a collaboration amongst all of you.
and each of you is probably going to have to give something up...
(unless you can find a sharp way to tease out all the ambiguities.
which, if you _can_ do that, will be the best solution for everyone.)
> Still, thanks for your analysis. It's refreshing to have
> an outsider's opinion one time in a while.
hey, who you calling "an outsider"? i was researching light-markup
years before gruber and swartz came along. this is my house, and
you kids better stop playing on my lawn... outsider my ass! ;+)
seriously, though, markdown has been great for light-markup, and
i sincerely hope that you guys move markaround to the next level...
> Fish, eh? I thought I smelled something…
you funny! :+)
but if you sincerely want to "call" it, you can.
i have promised to release my app when i get
100 people signed-up on this web-page here:
once i put it out in the world, you can criticize it
to the depths and heights of your heart's desire.
yes, i'm sittin' here, right on the edge of the dunk-tank,
daring you to step up and fire a hardball at the target...
> Extensions address the question of limited scope, and
> if they are to grow useful, it seems reasonable to inform them
> with a more abstract purpose; e.g., enriching plain text with
> logical structure, rather than making macros for html.
that's quite astute.
> You may also look at the syntax specification for kramdown
you've done a very good job, thomas, really a smashup job...
my reservation is based on my reaction that "this isn't simple".
that might be the way you've explained it. (like michel's work,
your documentation seems to be aimed at the _format_wonks,_
who care about "block level versus span level" and such things.)
or it might be that the underlying framework is just too difficult.
(specifically, i wonder if all the hassles of "lazy syntax linewrap"
outweigh the convenience... in my own work, i had to offer that
-- as project gutenberg files have mid-paragraph linebreaks --
but i worked out a way that it doesn't have to be quite so hard.)
so i just can't tell if it's the documentation or the framework, but
either way, if you can't find a more simple way to explain all of it
to ordinary people, i'm afraid you ain't gonna get a lot of uptake.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Markdown-Discuss