Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

Nicely done, and needed! But pretty much everyone I know who has used markdown has wandered into the swamp that is known as 'tables of despair'.

Michael Fortin's syntax is pretty useful and quite close to the spirit of Gruber's original efforts. (who hasn't done ascii tables with | and - right?) Until tables are 'standard' I do not hold out a lot of hope for widespread adoption.

That said, I really love taking it Markdown to this next level. And am moderately amused by the recurrence of the themes over time. I'm a old RUNOFF user from back in the day.

View on HN

I'm actually kind of happy that tables are complex

With the use cases for markdown, table seem inappropriate.

What I mean: tables are good at representing arbitrary data, particularly sets of data stored somewhere.

Maybe it would be better to simply describe the data with json embedded in markdown and delegate representation to something else.

The counter argument is that simple tables are simple. And as silly as that sounds, a typical expository essay might easily include a 2 x 2 'table' to explain some principle (I call them McKenzie tables since every presentation from those guys seemed to include one or more). Or simple columnar data like the current price of the Macbook pro line, or any number of things that are represented easily and efficiently in a simple table. That is why I like Fortin's syntax something like:

   | widgets  | quality level | cut-off point
   | :------- | :-----------  | :------------
   | frobs    | 98%           | 90%
   | bolts    | **65%**       | 70%
   | splangs  | 85%           | 80%

Reads easily in text and markdown's easily as well using multimarkdown (my current go to implementation). Use your CSS to style the selectors tbody, thead, and colgroup and you're off to the races.

The problem that I see with that is it makes editing a table very difficult. Sure, if you know exactly what you're going to put in a table, then it might be worth it to draw all of those lines, but as soon as you need to go and edit the content of a cell, or remove a column or something, you might have to go and edit unrelated parts to maintain your formatting. It also seems like it'd be a real pain to parse. I'm not sure I know of a better solution, except to suggest that markdown might not really be suited for tables, and it's better to just use HTML for that part.

In Github-flavored markdown, the spacing is optional. So it's actually easier to edit than an HTML table. Though a WYSIWYG editor is still beneficial for these kind of things.

https://help.github.com/articles/github-flavored-markdown#ta...

Not quite related, but if you haven't seen how emacs and org-mode handle ascii tables, it's pretty amazing! It will reflow automatically, and tabbing works just like you would expect in a spreadsheet application.

It's amazingly easy to run into simple writing tasks that require tables. E.g. if I write a simple product review, I might want to produce a comparison table rather than describe differences in long-winded and opaque prose.

We're trying to move our news writers to use markdown to author articles, but without tables, it will be pretty hard.

Having you tried kramdown? I find it well implemented & has table support. We use it at our compamy.

http://kramdown.gettalong.org/

Kramdown is awesome! Love the way it allows you to easily add only the parsers you need. Plugs right into my Rails app as well.

Reply on news.ycombinator.com