Re: Proposed table specification (long!)
On Wed, May 18, 2011 at 08:28:53PM +0200, Chinyoka on Macbook wrote: I am also wondering whether there would be a way to split a document into many pages. I checked with other Markdown implementations and wish they would have a way to split a document into pages: for instance, Cramdown looked like it could if Thomas wanted to make it one of those options you can put between those sharp brackets and colons. I take the view that markdown is really a text processing filter rather than a publishing solution, so this feels very out of scope. Perhaps something like emacs muse-mode (which I think has some limited markdown functionality,) or just the right Makefile could do the processing you want to get multi-page output. In short: it's a good feature but enough depends on the rest of your publishing process/solution, so look there. Currently, I am using PHP Markdown Extra for my web publishing, but want a solid desktop option. I sometimes wish there were a desktop version, whether command line or GUI, that would work like that PHP Markdown Extra. So I hope your solution may be the answer to this. Anyway, it looks like Markdown in 2011 is heading for exciting moments with or without Gruber's blessing. I used PHP Markdown Extra for years with a WordPress site. When I stopped that, I had a bunch of vanilla markdown with footnotes (and maybe images?) in the markdown extra. I continue to write text in the same way, and have been processing this text both on the web and locally using: Maruku (abandoned for speed reasons, but it's good for LaTeX conversions and one-offs,) and MultiMarkdown pretty much without error. I'm given to understand that python markdown and pandoc would also do what you want in terms of the extra syntax... Hope that helps, tycho -- tycho(ish) @ ga...@tychoish.com http://tychoish.com/ http://criticalfutures.com/ don't get it right, get it written -- james thurber pgpcLD5qlwpTo.pgp Description: PGP signature ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
thomas said: yes, the syntax spec is not aimed at the plain user, but the quick reference is. It's vastly simplified yes, the quick reference is much simpler, and thus better... and we could discuss why, but my sense is that nobody here really wants to talk about it any more, at least right now, so i'm happy to wait until next year, when it comes up again... -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
david said: Okay, so you're trolling. whoa. now _that's_ certainly an ironic twist. you demean me, repeatedly, and then have the audacity to go accuse _me_ of trolling, all while you spin the conversation in circles... that definitely takes some chutzpah, yes it do. at any rate, david, if you think format wonks add value to the equation, you can tell us how. in the meantime, i'll stand by my assessment. if anyone wants to get back on-topic, i'm game. -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
i said: if anyone wants to get back on-topic, i'm game. and now i add that if your posts are not on-topic (i'm looking at you, christian), i am _not_ game... so don't bother trying to play me. -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Yeah, let's all get back on topic, 'coz bowerbird said so. What was the topic again? Oh, trolling on how everyone want to make his own personal markdown spec. I've nothing to add than that it's their own decision. Chris. On Fri, May 20, 2011 at 9:56 AM, bowerb...@aol.com wrote: i said: if anyone wants to get back on-topic, i'm game. and now i add that if your posts are not on-topic (i'm looking at you, christian), i am _not_ game... so don't bother trying to play me. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On 2011-05-20 03:44 -0400 bowerb...@aol.com wrote: at any rate, david, if you think format wonks add value to the equation, you can tell us how. in the meantime, i'll stand by my assessment. The syntax specification for kramdown is complicated, sure, but trying to explain the corner cases and how the implementation handles them is just not that easy. So, yes, the syntax spec is not aimed at the plain user, but the quick reference is. It's vastly simplified but provides a quick overview of the available syntax. And if something doesn't quite work the way a user expected, he/she can always have a look at the specific section in the syntax specification, no need to look at the code! And the last part (no need to look at the code) is one thing that I tried to avoid with the syntax specification. It can be read by anyone and doesn't require the knowledge of a certain programming language. -- Thomas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
the big secret is that all you must do is split the text on blank lines, and then just decide what each segment is, which will tell you how it needs to be tagged/formatted. that's it, folks. it ain't rocket science. it's simple as pie. Wow. I wish I had realized this back in 2005 when I started working on my Python implementation. All of those hours wasted, while all I had to do was split the text on blank lines. I think this deserves to be added to The Collected Sayings of Bowerbird. (Just google). - yuri ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
I thought the topic was a proposed table specification? Like it says in the subject line? Somehow it ALL got off-topic. On 05/20/2011 04:05 AM, Christian Sciberras wrote: Yeah, let's all get back on topic, 'coz bowerbird said so. What was the topic again? Oh, trolling on how everyone want to make his own personal markdown spec. I've nothing to add than that it's their own decision. Chris. On Fri, May 20, 2011 at 9:56 AM, bowerb...@aol.com mailto:bowerb...@aol.com wrote: i said: if anyone wants to get back on-topic, i'm game. and now i add that if your posts are not on-topic (i'm looking at you, christian), i am _not_ game... so don't bother trying to play me. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net mailto:Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
yuri said: Wow. I wish I had realized this back in 2005 when I started working on my Python implementation. All of those hours wasted, while all I had to do was split the text on blank lines. well, yes, it woulda saved you a few years of time, eh? luckily, by 2008, you'd sensed that this was the solution, judging by this passage you left on this listserve in march: Let's first unambiguously specify how markdown text ought to be parsed into paragraphs, quotes, lists, etc. Michel, do you want to do a first draft and circulate it? michel did the first pass, on a draft which then... fell flat. and now, 3 years after _that_, michel is currently saying: 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 you guys can run around in circles all you like, until you finally decide you're gonna work together to accomplish this objective, and then, when you do, you can revisit my advice, whereupon you'll find it is exactly what you need. i'm _not_ telling y'all that you have a problem. i have _no_ desire to do an intervention on you. do what you like, guys. it's jeff atwood who was telling you that you have a problem. i say if you want to remain islands, i'm perfectly fine with it. but if/when _you_ decide that you have a problem, well then you will probably also realize that i've given you the solution. because, after all, you'd seized upon the solution yourselves, years ago; you just didn't realize that you had found the key. (or, if you did realize it, you didn't use it to unlock the door.) *** and i _invite_ you to add all of this to the collected sayings. except it hasn't been updated in a long time. you know why? because the guy who created it was in a long-running dispute with me about how p.g. should proceed. i said light-markup and he said t.e.i. (as if volunteers at p.g. could handle t.e.i.) finally, about a year back, he realized he was wrong all along. he still won't _admit_ that, but he quietly shifted his efforts to -- guess what -- light-markup, in the form of restructured text. how does that saying go? first they laugh at you, then they ignore you, then they fight you, then you win. and how does that other saying go? he who laughs last laughs best. -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
david said: The idea is not ascii formatting, it's the particular type of ascii formatting. there's nothing special about the particular type of ascii formatting represented by markdown, as it simply leveraged existing methods of ascii formatting found in e-mail and on usenet. nothing unique there. indeed, the important point was that it was pre-existing. Markdown tries to take advantage of existing methods of ascii formatting found in mail and usenet news right. i'm glad we agree. i used them too, and threw in huge dollop of the practices already in use by project gutenberg for their e-texts, since my specific aim was the p.g. library, as an existing corpus of digitized books that would serve as content for my general target, which was electronic-books across the full spectrum. (that's still the focus of z.m.l. -- e-books, not web-pages.) of course, project gutenberg also derived their conventions from those used in e-mail, and usenet, and bulletin-boards. so everyone, including markdown, gets these conventions from the same place -- the humans who invented them using the keyboards under their hands. (and typewriters, let us not forget; underscores, representing _italics_, came from typewriters; so some of this stuff is really old-school.) and it's probably good to remember that project gutenberg was using this intuitive formatting way back in the 1990s. when aaron swartz was really young, aged in single digits... if markdown was the inspiration for you personally, i'm glad. but markdown is assuredly _not_ where the idea came from. it was already an old idea by the time markdown came about. I had a vanity markup language once, too. i'll see if my users end up having a response to that charge...:+) *** ishe said: I don't know how on earth I can add my signature to be the 90th. don't worry, ishe. i will consider you signed up. it is informal. But I find that promising thanks. i hope you find that i deliver on the promises as well. and just wonder whether it would work on Mac as well. mac first. p.c. two seconds later. linux if there's any demand. (but since cory doctorow signed up, and sent a flock of people to sign up as well, i guess i will have to resolve myself to that.) I am also wondering whether there would be a way to split a document into many pages. that will be a feature that i will provide sooner rather than later. (the .epub format essentially demands that chapters be treated as separate files, so a chapter-based split will be offered first.) -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
david said: If you're defining how a language works, you need to aim it at the technically competent. if you want the masses to use it, you must aim there. Different audiences want different information. true. but trite. to the point it might as well be wrong. there are infinite audiences possible, but there are only 3 worth considering, and only 2 of those 3 matter. and thomas and michel were aiming at the format wonks, who are the third group, the one that doesn't even matter. they don't matter because they fail to add any real value. that's why thomas and michel were just wasting their time, in my humble opinion. who cares what format wonks think? so let's concentrate on the other two groups instead, ok? users are crucial, because without them you are nothing. and programmers matter, since you need implementers. users need something simple, and hopefully unambiguous. programmers need unambiguity, and it's best if it's simple. if you make your thing simple _and_ unambiguous, bingo! *** albert said: I imagine the emergence and vitality of a standard syntax (among other things) would benefit if everyone were familiar with this book: also astute. but unduly circuitous. usually i hate to give up my hard-fought trade secrets. and the more big, and obvious, and brilliant, they are, the more that i hate to give 'em up, precisely because it is exactly that first step where most people go bad, as evidenced right here by what albert said. but still, markdown and its implementers have suffered enough, so please consider this to be my open-source gift to you: the big secret is that all you must do is split the text on blank lines, and then just decide what each segment is, which will tell you how it needs to be tagged/formatted. that's it, folks. it ain't rocket science. it's simple as pie. reverse-engineer your syntax from that for unambiguity. simple, and unambiguous. that's all you need for bingo! but bravo for bringing up bringhurst, mr. skye. -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On 2011-05-17 19:49 -0400 Michel Fortin wrote: 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, first by creating a tool to be able to evaluate what each implementation do when encountering an edge case (Babelmark, which is now hosted at http://babelmark.bobtfish.net/), then by starting writing such a specification (see http://michelf.com/specs/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. You may also look at the syntax specification for kramdown (see http://kramdown.rubyforge.org/syntax.html) which *should* provide an unambiguous reference to how kramdown parses a Markdown (kramdown) document. -- Thomas ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Thanks for the great publishing system but I failed to add my comment to the already 89 ones I saw due to the verification code. Tried the audio one but to no joy, so hey I don't know how on earth I can add my signature to be the 90th. But I find that promising and just wonder whether it would work on Mac as well. I am also wondering whether there would be a way to split a document into many pages. I checked with other Markdown implementations and wish they would have a way to split a document into pages: for instance, Cramdown looked like it could if Thomas wanted to make it one of those options you can put between those sharp brackets and colons. Currently, I am using PHP Markdown Extra for my web publishing, but want a solid desktop option. I sometimes wish there were a desktop version, whether command line or GUI, that would work like that PHP Markdown Extra. So I hope your solution may be the answer to this. Anyway, it looks like Markdown in 2011 is heading for exciting moments with or without Gruber's blessing. Thanks Ishe Mobile number: +263 772 930 422 WEB URL: www.chinyoka-educational.com Skype ID: sunshinechinyoka On 18 May,2011, at 7:21 PM, bowerb...@aol.com wrote: slept on this, but decided to send anyway, make it a trilogy... *** david said: 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: http://www.pgdp.net/phpBB2/viewtopic.php?t=4311start=0 http://www.pgdp.net/wiki/Formatting_Examples/Gallery_of_Table_Layouts *** rob said: 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... *** michel said: 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. that's right. 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
Re: Proposed table specification (long!)
On May 17, 2011, at 1:46 PM, bowerb...@aol.com wrote: david said: I think this is a case where you'd do better writing a table preprocessor that implements your table extension. Yours is a fairly complex implementation i don't see anything complex in simon's formulation... i'd guess i could probably program it in a couple hours. and most of that would be fighting obtuse .html specs... Well, then why don't you do it? It looks like Simon would welcome your assistance, and if you could write him an implementation of his table design then he could get down to the interesting part of testing it and making sure it works to his satisfaction. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
here's another one i thought twice about posting, but what the heck... *** ok, first of all, when i referred to 39 implementations, i wasn't being critical. how could i criticize any of you for being off writing your own version of markdown when i'm off writing my own version of light-markup? my work _does_ predate that of gruber and swartz, but i've still continued to do it, because i think my method is _superior_ for the task at which my method is aimed; thus i am not willing to concede the race to markdown. so far be it from me to stab any of you for continuing to pursue your own entry because you believe it to be superior to the other contenders. believe in yourself! at the same time, though, it's a bit disingenuous to say that the only differences are your choice of languages. very few of you agree on edge-cases, and none of you have explored the entire arena. that's the reality here. and that is not a dig, either. the edge-cases are hard, and if you try to chart the whole arena, you will likely lose the simplicity that is one of markdown's big assets. anyone tempted to move in that direction should look at asciidoc. it's very admirable in a way, but it's not simple. who needs to reinvent .html markup without the brackets? so, believe me, i understand the conundrum very well... but still remaining at the same time, let us ask simon if he thinks there is any desire to find a compromise here. when it comes to tables, you put people in a catch-22... it has to be something that can work with existing tools, and it has to be something that can work with fonts that are proportional and nonproportional. surely you are all smart enough to know that the clauses are contradictory. the only reason to put people in a double-bind is if you actively want to stall 'em out, in a passive way. that's it. edge-cases are not as clear of a catch-22, but even there, you all have historic content you prefer not to break by changing your implementation, so you are at an impasse. but hey, if it makes you feel better, i would be happy to add that all of this is only in my own humble opinion, and that maybe i'm just not smart enough to see your solution, and whatever other evasive language i would need to say so as to protect you from feeling challenged or threatened, because that's really _not_ my intention. i have my own fish to fry... -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Le 2011-05-17 à 17:24, bowerb...@aol.com a écrit : when it comes to tables, you put people in a catch-22... it has to be something that can work with existing tools, and it has to be something that can work with fonts that are proportional and nonproportional. surely you are all smart enough to know that the clauses are contradictory. the only reason to put people in a double-bind is if you actively want to stall 'em out, in a passive way. that's it. edge-cases are not as clear of a catch-22, but even there, you all have historic content you prefer not to break by changing your implementation, so you are at an impasse. but hey, if it makes you feel better, i would be happy to add that all of this is only in my own humble opinion, and that maybe i'm just not smart enough to see your solution, and whatever other evasive language i would need to say so as to protect you from feeling challenged or threatened, because that's really _not_ my intention. i have my own fish to fry... 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, first by creating a tool to be able to evaluate what each implementation do when encountering an edge case (Babelmark, which is now hosted at http://babelmark.bobtfish.net/), then by starting writing such a specification (see http://michelf.com/specs/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. HTML5 had some companies to back its development, Markdown doesn't. And it's not like any of us is making money selling our implementation of Markdown (or at least I don't), so I'm not sure how it'll happen. Still, thanks for your analysis. It's refreshing to have an outsider's opinion one time in a while. -- Michel Fortin michel.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On Tue, May 17, 2011 at 4:24 PM, bowerb...@aol.com wrote: but hey, if it makes you feel better, i would be happy to add that all of this is only in my own humble opinion, and that maybe i'm just not smart enough to see your solution, and whatever other evasive language i would need to say so as to protect you from feeling challenged or threatened, because that's really _not_ my intention. i have my own fish to fry... -bowerbird Fish, eh? I thought I smelled something… -- Dr. Drang ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On 15/05/11 01:17 PM, bowerb...@aol.com wrote: simon- i'm not sure persistence will do you much good. nobody seems to have a desire to work together. which is likely why there are 39 implementations. Isn't the existence of 39 implementations due to each implementer having their own favourite programming/scripting lamguage? And don't most (if not all) strive to follow the canonical Gruber perl markdown implementation? The inability to work together as you put it is due more th the percieved apathy of the originators of markdown in the last few years and the lack of an appointed/accepted successor. an appeal on behalf of readers seems misguided, since very few people are reading markdown text. In my case I use markdown for a personal info management system and I read the text as often as the rendered html. But then it is my own text and I already know how I intended it to be interpreted. but a more potent case can be made for _re-use_. the more easily content can be remixed, the better. for my contender in the light-markup derby -- zen markup language (zml) -- to facilitate re-use, my goal is that users can round-trip the text... so if they copy the text out of the .pdf and use it to create _another_ .pdf, the two will be identical. likewise, if they copy the text from a web-browser, it will match the .zml file which created that .html. or copy the text out of one version (.html or .pdf) and use it to create the other version, just like that. i am coming very close in both cases. it'll certainly be the case that some global changes will always be required to restore the original .zml, but if i get it down to just a few, that will be an accomplishment. -bowerbird ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On Sun, May 15, 2011 at 2:01 PM, I wrote: I presume that the readers will be reading the entire document in html, via a viewer that renders html into a more pleasing format. On May 14, 2011, at 10:43 PM, Simon Bull wrote: However, what if you want to include a markdown document, or even just a fragment of markdown, in an email? It might be forwarded to many readers without ever being published as HTML. What if you want to write markdown for the purpose of a discussion group like this one? It might be read by hundreds of readers without ever being published as HTML. Additionally, if you would like to see markdown as a supported input format for tools such as wikis, forums, blogs, issue management systems, and so on (in fact, any tool where the source document itself can be retrieved, reviewed, and updated/edited inline) then your source document will possibly be read and reread by many users over the life time of the document. Perhaps these scenarios are worth considering too? I believe you are grasping at straws here.Now, there's certainly nothing horribly wrong with your proposed implementation, but I do wish to restate that you would be much better off writing some code that implements your proposal. It doesn't even have to do a full markdownification of the output; a skeleton that takes as input a document and translates your table blocks into html would be sufficient (and there are some markdown implementations that support a please markdownify me! flag for html block elements; if you add those flags to your generated html, you will have a program that can be pipelined like: simontable document.text | markdown document.html Don't convince us with words. Convince us with code. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
re: Proposed table specification (long!)
simon- i'm not sure persistence will do you much good. nobody seems to have a desire to work together. which is likely why there are 39 implementations. an appeal on behalf of readers seems misguided, since very few people are reading markdown text. but a more potent case can be made for _re-use_. the more easily content can be remixed, the better. for my contender in the light-markup derby -- zen markup language (zml) -- to facilitate re-use, my goal is that users can round-trip the text... so if they copy the text out of the .pdf and use it to create _another_ .pdf, the two will be identical. likewise, if they copy the text from a web-browser, it will match the .zml file which created that .html. or copy the text out of one version (.html or .pdf) and use it to create the other version, just like that. i am coming very close in both cases. it'll certainly be the case that some global changes will always be required to restore the original .zml, but if i get it down to just a few, that will be an accomplishment. -bowerbird___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On May 15, 2011, at 10:17 AM, bowerb...@aol.com wrote: simon- i'm not sure persistence will do you much good. nobody seems to have a desire to work together. which is likely why there are 39 implementations. Eh? I can't speak for 37 of the 39 implementations, but I know that in my case I *do* desire to work with the reference implementation; the detail that I'm doing it in G-d's own programming language(tm) was an artifact of not wanting to carry around Perl (Or python, or any of the other interpreted web scripting languages) just to have a reasonable markup language available to maintain my web pages. The existance of the markdown discussion list is pretty good evidence that there's a desire to work together. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Michel and Dr.Dang both commented that it is easier to author/edit tables as HTML than as aligned text. I am not sure I personally agree with this, but assuming that it is true for some significant part of the authorship, then I would like to add: In my original post I stated my belief that the needs of the _reader_ come before the needs of the _writer_. I don't agree that the needs of one author outweigh the needs of five hundred, ten, or even just two readers. The writer may well be inconvenienced once by having to align text into a table, but the *readers* are in inconvenienced n many times by having to read tables of HTML. Also, I believe that using the tab key to tab to the next column, or use of scripts similar to Dr.Dang's[1] to align selected text at the touch of a hot key should alleviate much of the authoring concern. Finally, adding support for a richer table syntax would in no way replace the existing support for HTML -- existing markdown documents containing tables as HTML (and other HTML) would of course continue to be valid. Therefore, HTML enthusiasts _could_ continue to author tables in HTML if they really could not tolerate aligning text into tables by other means. [1]: http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/ Simon On Thu, May 12, 2011 at 9:30 AM, Michel Fortin michel.for...@michelf.comwrote: Le 2011-05-11 à 9:41, Simon Bull a écrit : Thanks for your comments Michel. You're welcome. In reply to the points you raise: Regarding complexity: It is not clear to me whether folks are objecting to _parsing_ complexity or *reading/writing* complexity. Subjectively I don't think the example is difficult to read; it couldn't be much simpler. So I will assume that people are concerned about parsing complexity. It's pretty easy to read, no complexity problem there. I think the complexity lies in parsing, writing/editing, and explaining/understanding the possibilities. Implementation considerations should not drive the formulation of the specification except where some absolute technical limitation dictates otherwise. True, up to a point. It isn't worth investing tons of your time for a feature that'll benefit very few people (unless maybe yourself are one of those people, of course). A markdown document should be *publishable* _as-is_. Wobbly mis-aligned tables do not make publishable documents in any profession as far as I know. Well, the introduction says that indeed. Except that the role of Markdown is not to *enforce* this, but rather to *enable* it. And I'll say it's a success: most Markdown documents are indeed publishable as-is. In some circumstances however, the author has to make some efforts or find some tool to keep things pretty (multi-paragraph list items and blockquotes comes to mind). If you don't intend to publish the Markdown version, there is not much point to this effort and, thankfully, you can just skip it. Regarding ease of editing : The difficult with inserting text into a column is a general problem with text editing tools and table formats in general. It is not a specific problem with the proposed table syntax. My point about editing is that it's much easier to edit the HTML table than your table syntax because there is no grid to maintain. Regarding cell alignment : In my original post I wrote this The author has already provided the desired text alignment in the original (mono spaced) markdown text. It is therefore plausible for a parser to derive cell alignment by comparing the amount of leading and trailing white space in each table cell of each row and each column. I am the first to concede that this would require near-perfect spacing in the document, and would be very hard to implement. It is therefore unlikely that anyone would bother to implement it. Alignment deduction would likely be error prone too. However, there's no reason not to include MMD-style cell alignment meta-characters in the specification as a more practical short-cut if that is what people want. Indeed. Thanks again for your comments Michel -- I hope I was able to communicate my answers effectively and politely. It's an interesting discussion. -- Michel Fortin michel.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On May 14, 2011, at 6:08 PM, Simon Bull wrote: Michel and Dr.Dang both commented that it is easier to author/edit tables as HTML than as aligned text. I am not sure I personally agree with this, but assuming that it is true for some significant part of the authorship, then I would like to add: In my original post I stated my belief that the needs of the _reader_ come before the needs of the _writer_. I don't agree that the needs of one author outweigh the needs of five hundred, ten, or even just two readers. The writer may well be inconvenienced once by having to align text into a table, but the *readers* are in inconvenienced n many times by having to read tables of HTML. I presume that the readers will be reading the entire document in html, via a viewer that renders html into a more pleasing format. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Hi David, Yes, as the published form of a markdown document, the HTML representation of the document would presumably have a wide readership. However, what if you want to include a markdown document, or even just a fragment of markdown, in an email? It might be forwarded to many readers without ever being published as HTML. What if you want to write markdown for the purpose of a discussion group like this one? It might be read by hundreds of readers without ever being published as HTML. Additionally, if you would like to see markdown as a supported input format for tools such as wikis, forums, blogs, issue management systems, and so on (in fact, any tool where the source document itself can be retrieved, reviewed, and updated/edited inline) then your source document will possibly be read and reread by many users over the life time of the document. Perhaps these scenarios are worth considering too? Simon On Sun, May 15, 2011 at 2:01 PM, David Parsons o...@pell.portland.or.uswrote: On May 14, 2011, at 6:08 PM, Simon Bull wrote: Michel and Dr.Dang both commented that it is easier to author/edit tables as HTML than as aligned text. I am not sure I personally agree with this, but assuming that it is true for some significant part of the authorship, then I would like to add: In my original post I stated my belief that the needs of the _reader_ come before the needs of the _writer_. I don't agree that the needs of one author outweigh the needs of five hundred, ten, or even just two readers. The writer may well be inconvenienced once by having to align text into a table, but the *readers* are in inconvenienced n many times by having to read tables of HTML. I presume that the readers will be reading the entire document in html, via a viewer that renders html into a more pleasing format. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
I'm late to the party, but I do use tables in Markdown quite often, so… Apart from the complexity of implementation, Fletcher's point about monospaced and proportional fonts is the main objection to the proposed syntax. I always use monospaced fonts, but not everyone does, and Markdown is meant to accommodate everyone. Michel's point about editing tables is also spot-on and ties into the monospaced/proportional problem. Frankly, getting the proper alignment when writing a table for the first time, even when using a monospaced font, is a pain in the ass. Maintaining alignment when editing is even harder—your example of adding a full line to one of the columns covers only the simplest case. The great thing about Michel's table syntax is that it allows you to avoid these annoyances. You can align the columns if you want, but you're not forced to. I happen to prefer aligned columns, which is why I wrote this little script, http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/ to do the alignment for me. But that's done outside of Markdown itself; it's just a way of satisfying my anal retentiveness, not a prescription for others. Also, I'd like to address your use of rules within the table. Markdown generates straight HTML—styles are left to the user's CSS. By adding features that put borders in the table, you're inserting styles into Markdown itself, which I think is a mistake. Let me end by saying that I've always thought John was wrong not to include a provision for tables in Markdown, and Michel's syntax probably can be improved, so I welcome this discussion. But if tables are to be included they should be simple, in keeping with Markdown's overall approach. Markdown is not intended to handle every situation, just the most common ones. The table formatting you've presented is far more complex than the formatting Markdown does in other areas and, I would argue, is beyond what Markdown should do. Regards, Dr. Drang ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Thanks for your well considered comments Dr.Drang, I will take them on board along with all the others. Simon On Fri, May 13, 2011 at 2:33 AM, Dr. Drang drdr...@gmail.com wrote: I'm late to the party, but I do use tables in Markdown quite often, so… Apart from the complexity of implementation, Fletcher's point about monospaced and proportional fonts is the main objection to the proposed syntax. I always use monospaced fonts, but not everyone does, and Markdown is meant to accommodate everyone. Michel's point about editing tables is also spot-on and ties into the monospaced/proportional problem. Frankly, getting the proper alignment when writing a table for the first time, even when using a monospaced font, is a pain in the ass. Maintaining alignment when editing is even harder—your example of adding a full line to one of the columns covers only the simplest case. The great thing about Michel's table syntax is that it allows you to avoid these annoyances. You can align the columns if you want, but you're not forced to. I happen to prefer aligned columns, which is why I wrote this little script, http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/ to do the alignment for me. But that's done outside of Markdown itself; it's just a way of satisfying my anal retentiveness, not a prescription for others. Also, I'd like to address your use of rules within the table. Markdown generates straight HTML—styles are left to the user's CSS. By adding features that put borders in the table, you're inserting styles into Markdown itself, which I think is a mistake. Let me end by saying that I've always thought John was wrong not to include a provision for tables in Markdown, and Michel's syntax probably can be improved, so I welcome this discussion. But if tables are to be included they should be simple, in keeping with Markdown's overall approach. Markdown is not intended to handle every situation, just the most common ones. The table formatting you've presented is far more complex than the formatting Markdown does in other areas and, I would argue, is beyond what Markdown should do. Regards, Dr. Drang ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Notes from a writer who makes occasional light use of Markdown and is not involved in implementations at all (nor especially familiar with other -down table syntaxes): I view my plain-text emails in a proportional font (Verdana). Simon's tables look ragged that way, but readable and not terribly unpleasant. Such decoding of occasional monospace-intended bits is, in my view, a fairly conventional matter in email, and thus congruent with Markdown's inspiration. Perhaps the matter of mono vs. proportional is not such a bugbear after all, at least for small-to-medium tables (and for the rest, there's always HTML). But wait -- Given 2.1.b's handling of empty cells, it seems the proposal still assumes some degree of monospace involvement. Similarly, 3.1.a speaks of omitting a space-denoted column break from between two columns, a break that is between in a sense (either visual or numeric) that's likely obvious in monospace only. So in the proposal, colspans do depend on character counts, and thus on monospace writing tools (except in tables simple enough for manual counting). Well, I suppose most authors of Markdown texts use such tools anyway. A confusing bit for me: Section 2.3.b leaves me thinking that the compact form is usable only for single-row bodies, and NOT for, say, three rows and three columns as indicated in Section 1.1. Also, I'd suggest instructing authors to use blank lines as Gruber does instead of line breaks (as the latter connotes carriage returns and/ or newline characters). - TH Simon Bull wrote: ~ --- THE PEOPLE OF MIDDLE-EARTH --- PeopleHomelandTongue === Elves Rivendell, Quenya, Mirkwood, Sindarin, Lorien Nandorin Dwarves Erebor Khuzdul Hobbits The Shire, Westron Breeland ~ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Hello Thomas, In reply to your comments... Yes, I have assumed mono-spaced (or equivalent) rendering throughout. Comparing examples 1.1 and example 2.3.b, yes you are correct. I need to update the description given for 1.1 (the so called compact form). The compact form (without blank lines or rules between rows) will always result in a single table row with multiple lines per row. However, it would be possible to also specify a single line per row interpretation if that is a desired feature. Your comment re: line breaks versus blank lines is also taken on board. Thanks for your valuable comments, Simon On Wed, May 11, 2011 at 4:45 PM, Thomas Humiston t...@jumpingrock.netwrote: Notes from a writer who makes occasional light use of Markdown and is not involved in implementations at all (nor especially familiar with other -down table syntaxes): I view my plain-text emails in a proportional font (Verdana). Simon's tables look ragged that way, but readable and not terribly unpleasant. Such decoding of occasional monospace-intended bits is, in my view, a fairly conventional matter in email, and thus congruent with Markdown's inspiration. Perhaps the matter of mono vs. proportional is not such a bugbear after all, at least for small-to-medium tables (and for the rest, there's always HTML). But wait -- Given 2.1.b's handling of empty cells, it seems the proposal still assumes some degree of monospace involvement. Similarly, 3.1.a speaks of omitting a space-denoted column break from between two columns, a break that is between in a sense (either visual or numeric) that's likely obvious in monospace only. So in the proposal, colspans do depend on character counts, and thus on monospace writing tools (except in tables simple enough for manual counting). Well, I suppose most authors of Markdown texts use such tools anyway. A confusing bit for me: Section 2.3.b leaves me thinking that the compact form is usable only for single-row bodies, and NOT for, say, three rows and three columns as indicated in Section 1.1. Also, I'd suggest instructing authors to use blank lines as Gruber does instead of line breaks (as the latter connotes carriage returns and/or newline characters). - TH Simon Bull wrote: ~ --- THE PEOPLE OF MIDDLE-EARTH --- PeopleHomelandTongue === Elves Rivendell, Quenya, Mirkwood, Sindarin, Lorien Nandorin Dwarves Erebor Khuzdul Hobbits The Shire, Westron Breeland ~ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Le 2011-05-10 à 23:54, Simon Bull a écrit : If the proposed syntax overly complicated, I am very happy to simplify it. The question is whether or not the following is really complicated? ~ --- THE PEOPLE OF MIDDLE-EARTH --- PeopleHomelandTongue === Elves Rivendell, Quenya, Mirkwood, Sindarin, Lorien Nandorin Dwarves Erebor Khuzdul Hobbits The Shire, Westron Breeland ~ I agree with most of Fletcher's points. This is complicated. I made a parser that can parse something relatively similar to the above before settling on PHP Markdown Extra's current table syntax. I decided against it for a couple of reasons. First, it relies on spacing too much. With most syntaxes in Markdown, you can be lazy and not indent everything perfectly. This table syntax relies entirely on perfect spacing, which goes contrary to this principle. It also only work with monospace fonts which can be a problem in some cases. Second, editing its content is a real pain. Try to add a new elven tongue between Quenya and Sindarin and tell me how much time it takes. Now compare with editing the same table in HTML. I'll concede that the table is more readable than in HTML, but I think the ratio between usefulness and implementation effort is rather weak. And did I miss it or does it lacks one feature PHP Markdown Extra has: per-column left/right/center alignment? -- Michel Fortin michel.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On Wed, 11 May 2011, Simon Bull wrote: Thanks for your comments Michel. In reply to the points you raise: Regarding complexity: It is not clear to me whether folks are objecting to _parsing_ complexity or *reading/writing* complexity. Subjectively I don't think the example is difficult to read; it couldn't be much simpler. So I will assume that people are concerned about parsing complexity. On this I cannot comment except to say that I believe reading/writing considerations should drive the specification which should drive the implementation. Implementation considerations should not drive the formulation of the specification except where some absolute technical limitation dictates otherwise. Regarding spacing: Firstly may I say that I do believe good spacing is good practice for tables. From my original post... It is the _visual alignment_ of terms into rows and columns that enables a reader to recognise a table. Without any recognisable alignment, a reader sees a jumbled cloud of terms good doesn't have to mean perfect, however. Secondly, as an author I take pride in producing beautiful documents. If a document looks a mess then the author looks careless, lazy and less credible. Additionally, from JG's introduction at Daring Fireball: The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, A markdown document should be *publishable* _as-is_. Wobbly mis-aligned tables do not make publishable documents in any profession as far as I know. Regarding ease of editing : The difficult with inserting text into a column is a general problem with text editing tools and table formats in general. It is not a specific problem with the proposed table syntax. Moreover, various text editors do support a block or column select feature which enables the author to select, copy, cut and paste columns (or blocks) of text. This editor feature facilitates exactly the kind of operation you mentioned. That aside, the proposed table syntax supports a more trivial (lazy) method of inserting text into the middle of a column in a few seconds, like this: Before: People Homeland Tongue Elves Rivendell, Quenya, Mirkwood,Sindarin, Lorien Nandorin DwarvesErebor Khuzdul HobbitsThe Shire, Westron Breeland After: People Homeland Tongue Elves Rivendell, Quenya, Telerin, --- inserted text Mirkwood,Sindarin, Lorien Nandorin DwarvesErebor Khuzdul HobbitsThe Shire, Westron Breeland Regarding cell alignment : In my original post I wrote this The author has already provided the desired text alignment in the original (mono spaced) markdown text. It is therefore plausible for a parser to derive cell alignment by comparing the amount of leading and trailing white space in each table cell of each row and each column. I am the first to concede that this would require near-perfect spacing in the document, and would be very hard to implement. It is therefore unlikely that anyone would bother to implement it. However, there's no reason not to include MMD-style cell alignment meta-characters in the specification as a more practical short-cut if that is what people want. Thanks again for your comments Michel -- I hope I was able to communicate my answers effectively and politely. I want to go on record as a strong supporter of your efforts. Your willingness to consult your peers with this brain-storming effort does you credit! However, IMHO, at the end of the day, you must follow your intuition and good sense after taking all informed and uninformed opinions into consideration. I like your proposal! It will be interesting to use your proposal in due course. -- Duke Normandin Turner Valley, Alberta, Canada___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Thanks for your support Duke, It's good to get some positive feedback mixed in with the constructive criticism. I will take it all on board, as you recommend. Simon On Thu, May 12, 2011 at 12:02 AM, Duke Normandin dukeofp...@ml1.net wrote: On Wed, 11 May 2011, Simon Bull wrote: Thanks for your comments Michel. In reply to the points you raise: Regarding complexity: It is not clear to me whether folks are objecting to _parsing_ complexity or *reading/writing* complexity. Subjectively I don't think the example is difficult to read; it couldn't be much simpler. So I will assume that people are concerned about parsing complexity. On this I cannot comment except to say that I believe reading/writing considerations should drive the specification which should drive the implementation. Implementation considerations should not drive the formulation of the specification except where some absolute technical limitation dictates otherwise. Regarding spacing: Firstly may I say that I do believe good spacing is good practice for tables. From my original post... It is the _visual alignment_ of terms into rows and columns that enables a reader to recognise a table. Without any recognisable alignment, a reader sees a jumbled cloud of terms good doesn't have to mean perfect, however. Secondly, as an author I take pride in producing beautiful documents. If a document looks a mess then the author looks careless, lazy and less credible. Additionally, from JG's introduction at Daring Fireball: The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, A markdown document should be *publishable* _as-is_. Wobbly mis-aligned tables do not make publishable documents in any profession as far as I know. Regarding ease of editing : The difficult with inserting text into a column is a general problem with text editing tools and table formats in general. It is not a specific problem with the proposed table syntax. Moreover, various text editors do support a block or column select feature which enables the author to select, copy, cut and paste columns (or blocks) of text. This editor feature facilitates exactly the kind of operation you mentioned. That aside, the proposed table syntax supports a more trivial (lazy) method of inserting text into the middle of a column in a few seconds, like this: Before: People Homeland Tongue Elves Rivendell, Quenya, Mirkwood,Sindarin, Lorien Nandorin DwarvesErebor Khuzdul HobbitsThe Shire, Westron Breeland After: People Homeland Tongue Elves Rivendell, Quenya, Telerin, --- inserted text Mirkwood,Sindarin, Lorien Nandorin DwarvesErebor Khuzdul HobbitsThe Shire, Westron Breeland Regarding cell alignment : In my original post I wrote this The author has already provided the desired text alignment in the original (mono spaced) markdown text. It is therefore plausible for a parser to derive cell alignment by comparing the amount of leading and trailing white space in each table cell of each row and each column. I am the first to concede that this would require near-perfect spacing in the document, and would be very hard to implement. It is therefore unlikely that anyone would bother to implement it. However, there's no reason not to include MMD-style cell alignment meta-characters in the specification as a more practical short-cut if that is what people want. Thanks again for your comments Michel -- I hope I was able to communicate my answers effectively and politely. I want to go on record as a strong supporter of your efforts. Your willingness to consult your peers with this brain-storming effort does you credit! However, IMHO, at the end of the day, you must follow your intuition and good sense after taking all informed and uninformed opinions into consideration. I like your proposal! It will be interesting to use your proposal in due course. -- Duke Normandin Turner Valley, Alberta, Canada ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Proposed table specification (long!)
Gentlefolk, I have been thinking on Markdown's lack of proper table support for a long while now. Here's where I have arrived... ## I Don't Like HTML Tables It is often argued that embedded HTML is the way to markdown rich tables. Unfortunately, this contradicts the higher markdown ideal that a raw markdown document (including tables!) should be good 1. Firstly for readers, 2. Secondly for authors, 3. Lastly for parsers which don't even rate a mention because markdown is for Humans. You have probably noticed already that HTML tables are *appalling* for readers and a nightmare for authors. They are hardly good for markdown parsers either, which (not being HTML parsers) treat HTML tables as impenetrable blobs to be output as is. Where does that leave us when we want to go from markdown to PDF? ## I Do Like Monospaced Tables It is the _visual alignment_ of terms into rows and columns that enables a reader to recognise a table. Without any recognisable alignment, a reader sees a jumbled cloud of terms -- which is exactly how we see tables with a variable width font. Additionally, a raw markdown document should 1. Be sharable, and, 2. Convey the same information to every reader. A raw markdown document must therefore be rendered *equivalently* for every reader. This can only be assumed if every reader has the same text spacing, and a mono spaced is _a_ reasonable way of achieving this. With all that in mind, I offer up my Teardown table specification for your consideration (I realise it will be torn down, but nothing ventured nothing gained). Teardown offers the following over and above MultiMarkDown's table support: * Multi-line cell content, * Additional Arty syntax for titles and footers (much nicer for authors and readers), * Colspan (without meta-chars in cell content), * Rowspan, * Cell alignment (without meta-characters in content) *Please note* that I have _not_ implemented this specification. This is all just hot air produced by an author trying contribute something toward better table support for markdown. (specification to follow...) ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
## Teardown Table Specification 1. Teardown Tables 1. The Simplest Table 2. Basic Table Features 1. The Header a. Basic Header b. Multi-Line Header 2. The Title 3. Rows a. Clean Rows b. Multi-Line Rows c. Ruled Rows 4. Columns a. Clean Cols b. Ruled Columns 5. Ruled Rows and Ruled Columns 6. The Footer 3. Advanced Table Features 1. Cell Spans a. Rowspan b. Colspan 2. Cell Alignment a. Vertical Alignment b. Horizontal Alignment 3. Advanced Headers 4. Empty Cells 5. Nested Tables 6. Multiple Bodies 7. Vertical Table Header 4. Putting it all Together 1. A Complex Markeddown Table ## 1. Teardown Tables A table is an arrangement of terms into rows and columns. ### 1.1. The Simplest Table Here is a very simple Teardown table with three rows and three columns (examples are delimited by PHP Markdown Extra fence blocks throughout): ~ Elves RivendellSindarin DwarvesErebor Khuzdul HobbitsThe ShireWestron ~ It is the *visual alignment* of terms into rows and columns which makes the whole recognisable as a table to the reader. It is the two leading (and trailing) line breaks which signal the beginning (and end) of a table to the parser, however. Additionally, we can see that: * A line-break indicates a row-break, * Any 3 or more space symbols indicates a column-break. That is the _very least_ you need to know in order to write Teardown tables. ## 2. Basic Table Features The very least is not enough to satisfy all authoring needs. For example, empty table cells are not supported by Simplest Table (above). Teardown specifies a number of additional features which, combined, aim to address all but the most tricky cases. ### 2.1. The Header It is very often desirable to label columns of terms with a row of headings. If included, this row of column headings is called the Header. The Header is separated from the table Body by a line of equals symbols called the Line. The table Header is always above the Line, and the table Body is always below the Line. 2.1.a. Basic Header The Header is authored as per any other row in the table Body. It is a series of terms at the top of a like series of aligned columns. 3 or more space symbols denote a column-break, just as they do in the Body of the table. E.g., ~ People Homeland Tongue Elves RivendellSindarin DwarvesErebor Khuzdul HobbitsThe ShireWestron ~ 2.1.b. Multi-Line Header Header text can occupy more than line in the Header. E.g., ~ Name of Spoken People Homeland Tongue Elves RivendellSindarin DwarvesErebor Khuzdul HobbitsThe ShireWestron ~ Note the single line Homeland column header. Empty cells and cell spans are discussed in section 3 (Advanced Table Features, below). But even disregarding section 3, a parser can count the number of characters to determine which column the text Spoken belongs to. ### 2.2. The Title It is often desirable to label a table with a title. If included, a Title is any text between two unbroken lines of minus symbols which precede the table itself. E.g., ~ THE PEOPLE OF MIDDLE-EARTH People Homeland Tongue Elves RivendellSindarin DwarvesErebor Khuzdul HobbitsThe ShireWestron ~ ### 2.3. Rows Rows of columns make up the Body of a table. 2.3.a. Clean Rows Clean rows (so called because the markdown is uncluttered) are separated by a line-break. E.g., ~ People Homeland Tongue Elves RivendellSindarin DwarvesErebor Khuzdul HobbitsThe ShireWestron ~ Note that the more compact form used in example 1.1 (above) is ambiguous as to whether there are three lines of text in a single row, or a single line of text in each of three rows. In this example, there is no such ambiguity. 2.3.b. Multi-Line Rows Multi-lined rows are also allowed; ~ People Homeland Tongue Elves Rivendell, Quenya, Mirkwood,Sindarin, Lorien Nandorin DwarvesErebor Khuzdul HobbitsThe Shire, Westron Breeland ~ It is clear now that the compact form used in example 1.1 (above) would unambiguously be interpreted as three lines of text in a single row.
Re: Proposed table specification (long!)
On Tue, May 10, 2011 at 8:31 AM, Simon Bull waysoftheea...@yahoo.com.au wrote: Gentlefolk, I have been thinking on Markdown's lack of proper table support for a long while now. Here's where I have arrived... ## I Don't Like HTML Tables It is often argued that embedded HTML is the way to markdown rich tables. Unfortunately, this contradicts the higher markdown ideal that a raw markdown document (including tables!) should be good 1. Firstly for readers, 2. Secondly for authors, 3. Lastly for parsers which don't even rate a mention because markdown is for Humans. In response to this I will quote the paragraph from the syntax rules [1] which likely gave you this impression: Markdown is not a replacement for HTML, or even close to it. Its syntax is very small, corresponding only to a very small subset of HTML tags. The idea is not to create a syntax that makes it easier to insert HTML tags. In my opinion, HTML tags are already easy to insert. The idea for Markdown is to make it easy to read, write, and edit prose. HTML is a publishing format; Markdown is a writing format. Thus, Markdown’s formatting syntax only addresses issues that can be conveyed in plain text. Note that is says easy to read, write, and edit prose -- prose not tabular data. Taking this (along with the rest of that section of the document, it is clear (to me at least) that there is no place for a table syntax in markdown. Now, if you want to implement a third party add-on, fine. And if that third party add-on becomes popular, then maybe others will add it to there implementations as well. Maybe, eventually, if a single format becomes popular enough, the community at large will accept it. Until then, I'm not interested. If you want it, go build it! [1]: http://daringfireball.net/projects/markdown/syntax#html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On May 10, 2011, at 5:31 AM, Simon Bull wrote: Gentlefolk, I have been thinking on Markdown's lack of proper table support for a long while now. Here's where I have arrived... . . . *Please note* that I have _not_ implemented this specification. This is all just hot air produced by an author trying contribute something toward better table support for markdown. I think this is a case where you'd do better writing a table preprocessor that implements your table extension. Yours is a fairly complex implementation, and there's not a painless way for people to try it out.The existing table implementation (the php markdown extra one) is kind of klunky and horrible, but the code is there and authors can actually see a working implementation before going and implementing it themselves. Yours, at least as of right now, is just documentation and not very useful for getting ones fingers into the pie. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Thanks for your replies gentlemen. I'm not surprised by the lack of... enthusiasm. I would like to add, in reply to Waylan's comment about prose, that markdown already includes syntax for lists, link, horizontal rules, images and so on which are not prose either. Surely markdown can only be a more useful tool with table support than without it. I agree with David's comment that the specification needs an implementation before people will take it seriously. I did, however, think it was a reasonable notion to firstly propose a solution, then have it reviewed by a meaningful authority (i.e., this list), and then think about implementing it. I will leave it to simmer a while before I go any further with it. Thanks again, Simon On Tue, May 10, 2011 at 11:37 PM, David Parsons o...@pell.portland.or.uswrote: On May 10, 2011, at 5:31 AM, Simon Bull wrote: Gentlefolk, I have been thinking on Markdown's lack of proper table support for a long while now. Here's where I have arrived... . . . *Please note* that I have _not_ implemented this specification. This is all just hot air produced by an author trying contribute something toward better table support for markdown. I think this is a case where you'd do better writing a table preprocessor that implements your table extension. Yours is a fairly complex implementation, and there's not a painless way for people to try it out.The existing table implementation (the php markdown extra one) is kind of klunky and horrible, but the code is there and authors can actually see a working implementation before going and implementing it themselves. Yours, at least as of right now, is just documentation and not very useful for getting ones fingers into the pie. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Additions to the MMD table syntax (which is largely based on PHP Markdown Extra) is probably one of the most common feature requests I get. My response is usually always the same - I'll update the syntax when I see a proposal that is: * easy/natural to write * easy/natural to read * easy to program a computer to parse * uncluttered I realize that beauty is in the eye of the beholder in these cases, but I have yet to see a proposal that beats the current syntax in all (or even most) of these criteria. I would love to add additional features to MMD tables (cells that span multiple rows, improved syntax for wrapping long cell contents, etc) but not at the expense of further complicating the syntax. My $.02, Fletcher -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Hi Fletcher, Should I assume that you mean the proposed syntax falls short in one or more of the four categories you identified? If you care to elaborate on some of these short-comings I would be very happy to alter my proposal in order to meet the needs of a wider audience. That was in fact the purpose of proposing it at all. Thanks for your comments, Simon On Wed, May 11, 2011 at 10:37 AM, Fletcher T. Penney fletc...@fletcherpenney.net wrote: Additions to the MMD table syntax (which is largely based on PHP Markdown Extra) is probably one of the most common feature requests I get. My response is usually always the same - I'll update the syntax when I see a proposal that is: * easy/natural to write * easy/natural to read * easy to program a computer to parse * uncluttered I realize that beauty is in the eye of the beholder in these cases, but I have yet to see a proposal that beats the current syntax in all (or even most) of these criteria. I would love to add additional features to MMD tables (cells that span multiple rows, improved syntax for wrapping long cell contents, etc) but not at the expense of further complicating the syntax. My $.02, Fletcher -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
Since you asked, here are my own personal thoughts - others most likely disagree The syntax seems a bit complicated - I didn't compare, but I suspect the length of your explanation approaches or exceeds the entire Markdown syntax guide. I realize that you are trying to offer some flexibility, but that can get tricky. The other challenge is editability - with most of the complex table formats out there, it would be very tedious to actually create and subsequently modify a table by hand. I will grant you that this as much (or more) a problem with editors than the syntax. And one could create plugins for certain editors (e.g. TextMate) that could do the formatting for you. But this seems to be straying outside the bounds of what makes Markdown so great. (Again --- just my opinion) But I think the biggest issue is the monospace vs proportional font problem. This plagues every proposed table syntax out there (to my knowledge) --- tables just aren't going to look right in both font types in plain text files. Proper alignment is a key feature of tables, and it's frustrating when this is destroyed by changing the font. That said, the elastic tabstop idea proposed by Nick Gravgaard offers a tantalizing solution to this problem. In text editors that supported this concept, it would be trivially easy to align columns of text that worked for both monospace and proportional fonts. Columns would automatically realign when you changed the length of a given cell. In general, I believe there is a trade-off between simplicity and functionality. My preference is not to sacrifice (much) simplicity for the sake of functionality --- I believe MMD's table syntax is about as far down that curve as I am willing to go. Others may be on the other end of the spectrum. Where true genius comes is being able to merge simplicity with functionality (e.g. the iphone). I'm not saying a great solution for the Markdown/Table dilemma doesn't exist. I just don't think I've seen it yet. But I agree with you that continuing to generate new proposals is a good idea. F- On Tue, May 10, 2011 at 9:22 PM, Simon Bull waysoftheea...@yahoo.com.au wrote: Hi Fletcher, Should I assume that you mean the proposed syntax falls short in one or more of the four categories you identified? If you care to elaborate on some of these short-comings I would be very happy to alter my proposal in order to meet the needs of a wider audience. That was in fact the purpose of proposing it at all. Thanks for your comments, Simon -- Fletcher T. Penney fletc...@fletcherpenney.net ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Proposed table specification (long!)
On May 10, 2011, at 8:54 PM, Simon Bull wrote: Thanks for your additional comments Fletcher. If the proposed syntax overly complicated, I am very happy to simplify it. The question is whether or not the following is really complicated? Implement what you have, and then you'll have an idea if it's too complicated. Working code is the best test of the complexity of a design. -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
