Re: Markdown development
* David E. Wheeler da...@kineticode.com [2010-03-20 23:05]: I'm pretty happy with MMD definition lists (with s/:/~/g) I tried to like them. and with psql-style tables (mostly implemented in Markdent::Dialect::Theory. I find them both esthetically pleasing. They look OK but are a pain to edit. (I haven’t seen a table syntax that I find easier to edit than raw HTML. Well, the fact that Markdown won’t touch the contents makes them still a pain.) I think this editing|reading tension is fundamental, therefor not resolvable. * Sherwood Botsford sgbotsf...@gmail.com [2010-03-20 23:35]: G. K. Chesterton commented, If something is worth doing, it's worth doing badly Only within limits. I like MMD's table syntax. Not perfect. Still a pain to construct, especially if you want to keep the notion of having to look reasonable as plain text. But it *really* beats tablethtd.../thtrtd/td.../tr.../table To look at? Beats it. To write? Not hardly. Esp. if you leave off the closing tags, as I do these days when I write tables in Markdown documents. At this point I can do it with template toolkit and include files, but it's more than a bit rube-goldbergish. In the league with programmable candle powered hydralic peanut butter spreaders. Actually include files are how I would suggest you do that. Better yet use a Markdown implementation where you can pass a prepopulated table of link references (so that the Markdown formatting won’t have to parse the same 1,400 link references over and over). Easy way to modify the behaviour with certain tags. One of the things I want is some way to make it easier to tell Markdown to re-engage inside block tags, in a less klunky fashion than Markdown Extra’s (I think?) markdown=1 pseudo-attribute. I don’t have a good idea for this, though. I wouldn’t want any configurable behaviours, though. To me it is a very important point that you can take a Markdown document from one environment to another without breakage. * Seumas Mac Uilleachan seu...@idirect.ca [2010-03-21 00:45]: I hear constantly about needing Gruber's blessing for any overhaul or changes to Markdown. Why? In case you are referring to my own recent mail, I never said it needs *Gruber*’s blessing specifically. What it does need is one central voice. If you think it doesn’t, then ask yourself why all of the reimplementations have added their own features, yet none of them have copied each other. Except that several of them have copied Markdown Extra. As it happens, Michel Fortin had some blessing from Gruber on several of his efforts. Coincidence? No one needs permission or blessing to fork Markdown. Many people have done it. But that’s the point. To get more than Just Another Fork, it neds to have weight of voice to bring all the other forks together behind it. The goal of markdown is readability. There is no such thing as a readable html table. I would argue that tables are a useful enough feature to include. Whether it is done badly or well is often subjective. At the minimum a simple table format would be important to me (not requiring spanning cells or complex table layouts). Tables are the easiest way to list corresponding values or data that they really should be somehow included. The problem with tables as I see it is as above: I think that tables fundamentally cannot be both easy to edit and easy to read within the constraints of plaintext. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Markdown development
On Mar 21, 2010, at 6:13 AM, Aristotle Pagaltzis wrote: They look OK but are a pain to edit. (I haven’t seen a table syntax that I find easier to edit than raw HTML. Well, the fact that Markdown won’t touch the contents makes them still a pain.) I think this editing|reading tension is fundamental, therefor not resolvable. Well, I didn't have that issue with the definition lists (the formatting is not, after all, all that different from unordered lists), but agree with you on tables. I likely would load data into PostgreSQL and let psql format things for me for all but the simplest tables. But at least I'd have that tool. The advantage over HTML is of course plain if you want them to be legible as plain text. I wouldn’t want any configurable behaviours, though. To me it is a very important point that you can take a Markdown document from one environment to another without breakage. +1 In case you are referring to my own recent mail, I never said it needs *Gruber*’s blessing specifically. What it does need is one central voice. If you think it doesn’t, then ask yourself why all of the reimplementations have added their own features, yet none of them have copied each other. There doesn't need to be one voice, but one spec would definitely be valuable. There can be community consensus building toward developing that spec, but a dictator is hardly necessary. But that’s the point. To get more than Just Another Fork, it neds to have weight of voice to bring all the other forks together behind it. Or the consensus of those on this list, especially if Gruber were to formally resign. The problem with tables as I see it is as above: I think that tables fundamentally cannot be both easy to edit and easy to read within the constraints of plaintext. No, but one can use tools to format them when necessary. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
