#Markdown ufocus code

#Markdown ufocus code

Code fences have room to let you indicate the language of the code content, and have even been extended to offer other metadata: ```jsĪdding code titles and line highlighting was probably a step too far for Gruber’s goals, but the core idea is that code fences are more extensible than code blocks - and, it turns out - useful for readers of the unprocessed markdown too! This blogpost you just read would be unreadable - and therefore unwritable - without code fences.Ĭode Blocks have another related, smaller problem - they coincide with hanging list indents. First, they weren’t designed with developer tooling in mind. It’s convenient to toggle what is or is not a code block just by tabbing content in and out.īut of course, code is code, and words are words - we don’t just switch them back and forth willy nilly, they’re drastically differnt types of content. It’s maaaybe possible to see why Gruber picked 4 spaces/1 tab (let’s not have THAT debate) to indicate a codeblock. Markdown will generate: This is a normal paragraph: This is a code block. For example, given this input: This is a normal paragraph: To produce a code block in Markdown, simply indent every line of the block by at least 4 spaces or 1 tab. Markdown wraps a code block in both and tags. Rather than forming normal paragraphs, the lines of a code block are interpreted literally. Pre-formatted code blocks are used for writing about programming or markup source code. Here’s how Gruber explained them in the spec: Just to be clear what we’re talking about - Code Blocks are how you indicate code (with 4 spaces), whereas Code Fences are the thing more people probably use today (with triple backticks). Code BlocksĬode Blocks probably aren’t necessary, and overlap with 2 important commonly used (but not headline) Markdown syntax features. This would be even easier to remember had Gruber not chosen to allow * for unordered lists instead of the pretty-much-universally-used - (and the never-used +) - but it’s common for lexers to recognize sets of two characters ( *.) over one ( *). Pretty sweet!Īs a further thought exercise, we could support lazy numbering with some other character than a 0-9 number: 300. Does that give us any value in HTML?Īnd if the author were to need out-of-order numbers for whatever reason, that would be supported out of the box as well. Normal li elements don’t care about what order you leave them in: Bird McHale Parish īut given that in Markdown we’re already typing numbers, having numbers be order independent kind of loses the meaning of using numbers at all. I can understand why Gruber went for it: HTML itself is pretty lazy. In practice, more people will reorder their numbered lists just to make it look right in markdown (either manually, or with tooling). But we read markdown more than we write it - even as the people writing it! It is a design philosophy of Markdown. This laziness is good for, well, the lazy. But if you want to be lazy, you don’t have to. The point is, if you want to, you can use ordinal numbers in your ordered Markdown lists, so that the numbers in your source match the numbers in your published HTML. If you instead wrote the list in Markdown like this: 1. In Gruber’s original spec, this was the way he explained it: This post is an expanded tweet and you may enjoy the related HN discussion.

Here are 6 things it got wrong (in my opinion, of course). John Gruber’s Markdown is almost a perfect content authoring format.