I appreciate that it depends on your perspective and level of experience, but I would contend that having to write or adapt CSS adds too much friction to the process for most people.
My experience with the vast majority of templates is that they are geared for online output and to get something to print sensibly without using half a forest I need to…
Reduce the page borders
Make the font sizes for each style smaller
Reduce the line and paragraph spacing
As soon as you start doing this in CSS you run in to issues like
Which HTML elements to style (remembering that using Markdown is supposed to avoid the need to have to care about HTML in the first place) ?
Which property to adjust (Margin, Border, Padding etc) ?
Which units to use (pt, em, cm etc) ?
What the syntax is for the thing you want to change ?
Which styles apply to which output media ?
The variation in CSS support between browsers (e.g. Safari, which is the default rendering engine on iOS/iPadOS does not support the CSS at page rule)
I’ll stop there !
CSS is a great tool, but it is primarily aimed at web programmers, not end users who just want to make a few relatively simple tweaks to their output formatting.
So don’t get me wrong, I really love the Markdown concept of focussing on content first and I think there are some brilliantly innovative Markdown editors out there.
I just think there is an opportunity to optimise the back end of the workflow to make it easier to get from that content to a perfectly formatted end product, especially when it comes to printed output.
I really enjoyed this episode. I had to extend my walk just to hear the end of it. I was surprised that there was no mention of my favourite Markdown editor Typora. It is currently (and has been for years) free and in beta but for my money, is the best of both worlds. Type using markdown and, in the same window see the formatted text. I have a YouTube channel I use Typora for creating all of my scripts. Also, since my channel is on developing software using Swift, I love the fact that I can add not only code blocks, but code fences using ``` to surround the code. It is multi-featured and definitely worth the look. I even did a YouTube video on this app I love it so much. Markdown with Typora
Except we’re not talking about ‘most people’ - we’re talking about an individual on a ‘power users’ forum who has a specific desire to customize printed Markdown output using Marked 2 (an infinitesimally small group, I think you’d acknowledge) but won’t or can’t make a one-time change to customize CSS as a style. Customizing printed output of any kind in an app is usually complicated or difficult, depending on what you want to do; I don’t see other apps being substantially better at it, and I see other formats having numerous disadvantages already detailed.
Typora is a very powerful app and its WYSIWYG presentation has been years ahead of the competition (which is only now starting to catch up, or promise to). But otherwise it’s a pretty basic Markdown app.
“In these circumstances you might also collaborate using Google Docs or some other service that allows for simultaneously editing the master copy of a document. This may not be ideal, but it is better than not collaborating. There is little to be gained from plain-text dogmatism in a .docx world.”
^^I’m trying to keep this in mind while transitioning my academic workflow to plain text.
Some other useful resources for writing with md in research contexts:
I came here to post exactly that same tip.
I find this to be a handy and natural way to think of Markdown links (and I suppose it was consciously designed that way)
I develop and customize content management systems and we’ve found that markdown fields usually work better than WYSIWYG fields because markdown sets the right expectation for the user that the template is going to handle the presentation. Providing something that feels like Word, even with limited buttons, results in users trying to do too much with it.
I’m not a writer, with most of what I do write going on a presentation or the notes and the rich text in Keynote is the way to go there. Markdown is not for me really.
But, the fact that web services and text editors can provide simple formatting that I can use without effort is brilliant. I also use the syntax in emails sometimes because underscores either side of a word provide stress elegantly; they slow the reader just the right amount.
I loved this episode. I’ve been using Markdown since I bought David’s (and Eddie Smith’s) original Field Guide.
Drafts and 1Writer are my current two Markdown apps of choice. I use 1Writer for long-form fiction writing and I use Drafts for everything else (Emails, Texts, Notes, etc.). Drafts works on iOS and macOS and the sync is super-fast and reliable. 1Writer (iOS) saves individual plain text files to iCloud so that many Mac apps can access/edit them from there. If pushed, I could make do with Drafts alone, especially since the addition of the simple but powerful hyperlinking between drafts (using a Markdown-like syntax based on [[Double Square Brackets]].
On a future note, I hope we’re not too far away from seeing the fruits of the labour from Brett Terpstra and Fletcher Penney, who have been working on a replacement for Multi-Markdown Composer and nvAlt. I can’t think of two greater experts in this field, but the project is a long time coming. See this Blog Post from last year.
Oops, that went in a direction I wasn’t expecting. My comment wasn’t intended to cause annoyance so if it did then I apologise.
My point is wider than being able to style printed output in Marked 2 (which I would completely accept as being niche and isn’t my requirement anyway).
My use case is to create Markdown content (preferably in iA Writer on iPad) and then publish that content via a variety of channels including web, email and print, applying suitable formatting to each (I only highlighted print as it is often the trickiest). This is something that Markdown should be well suited for with its focus on content first and presentation later.
My observation is that with the current crop of Markdown tools, the options for tailoring the output seem to go straight from…
“Pick a template you like”, with little or no customisation.
to…
“Adapt a relatively chunky piece of CSS”, which offers great flexibility, but with a reasonably significant learning curve and lots of stumbling blocks waiting to trip up the unwary. This can easily turn into a significant time suck, which I think many people (myself included) would prefer to avoid when they are trying to focus on their content.
So all I was trying to express was my wish for a middle ground that offered a relatively simple customisation interface (e.g. the inspectors you get in Pages) that could then generate the output templates without the need to delve into the CSS code. In my book at least, this would be in line with the spirit of what Markdown was originally designed to achieve.
Until i read through this thread and find out that somebody already mentioned this:
Paragraphs have been at least for me the biggest mystery with markdown.
My feeling is there’s a lot of variation and inconsistencies between apps and md styles/flavors when it comes to
paragraphs, breaks, line breaks, nbsp, double spaces, and more.
Gruber says he wrote it to simplify writing in HTML. When you’re writing in HTML it’s too easy to leave off an angle-bracket or something and mess up your whole page. Markdown is designed to make that process more breakproof, and also make writing easier (less typing) and make the result easier to read.
A friend recently said that Markdown is kind of like a cult. I agree it can be, but to me it’s just a simple, but very useful shortcut for getting words down easy and quickly.
The whole podcast is worth listening to if you’re a fan of Gruber, as I am, and enjoy hearing about his writing process, which I do enjoy.
