appreciate a lot of the points made in the post but
```
distinct( *["code" in body[]._type] .body[_type == "code"] .language )
```
is "trivial" for no human being
Thoughts on Markdown
41–50 of 167 posts
Re: Thoughts on Markdown
#42Earlier quoted context omitted.
The biggest misunderstandings about LaTeX stems from comparing it with Microsoft Word or to any other word processor. LaTeX is a typesetter. You give the text, the template and the page size and it typesets it all. You nudge it with hints, and that's all. So, LaTeX is content first and layout second in a sense. On the other hand, word processors work at absolute terms, layout first. Looking to LaTeX from this perspec…
> "LaTeX gets the content and fits to the constraints at hand" I'll believe this when scientific papers start appearing in the form of reflowable HTML.
I don't think that'll happen anytime soon, because scientific papers are one of the rare species of publications, which are primarily made to be printed, read and mangled with pens.
Even the templates from the publishers came with paper sizes and other crop marks coded inside them.
When publications start accepting reflow able formats and provide relevant templates, producing them is easy with LaTeX.
Re: Thoughts on Markdown
#43Markdown is merely the lowest common denominator of what is essentially a jungle of weird and wonderful wiki languages. The reason it is so under-specified is that it emerged out of the Ruby community in a time where the whole point of Ruby was that it was a scripting language without a lot of appreciation for things like types or specifications. The first serious attempts to unit test and specify ruby itself actuall…
A good thing about it is that when a tool doesn‘t support a certain feature, it‘s usually graceful, because most syntax is designed to be usable as plain text, so just fall back too that.
Re: Thoughts on Markdown
#44I find this article to be sort of ridiculous. Sure, some of the critiques about the various flavors of Markdown might be valid (but I would posit that for the non-technical users the author claims to be so concerned about, the chances of them regularly having to interact with more than one flavor (and no, Slack and Reddit don’t count), is extremely low), but the whole piece seems to be an advertisement for the author's company's JSON-based rich text specification, which couldn’t be further away from the point of Markdown if it tried.
Markdown is for writers. The fact that it has been adapted and forked and flavored into something that many developers like is wonderful. But it is fundamentally for writers. And I’ve taught dozens, if not hundredS, of “normies” to use Markdown when writing for the web over the last 15 years. Some of them have hated it — which is totally fine - but many more have appreciated being able to write readable content for the web without having to do it in the CMS, which is always, always, always, a flat-out terrible idea. Or the other alternative, which is write in Google Docs or Word or Notion or whatever and then paste it into the CMS for the hell that will ensue.
There is a certain irony in the author claiming to want to make a better authoring system for users, but only in a way that adds complexity, requires developers to build UIs around its spec, and has benefits that really only appeal to the people building the CMS or trying to sell people on why their version of TinyMCE is best (oh, but you have to build the TinyMCE UI yourself…this is just another overly-complicated JSON spec that really is provably only suited by whatever it is Sanity is trying to hawk).
Markdown isn’t perfect. And it doesn’t claim to be. But in terms of being a readable and easily usable way to write content for the web, it’s pretty damn great.
Re: Thoughts on Markdown
#45Markdown is merely the lowest common denominator of what is essentially a jungle of weird and wonderful wiki languages. The reason it is so under-specified is that it emerged out of the Ruby community in a time where the whole point of Ruby was that it was a scripting language without a lot of appreciation for things like types or specifications. The first serious attempts to unit test and specify ruby itself actuall…
> Whatever the ruby markdown library did ...
FYI John Gruber's original Markdown.PL is written in Perl [1] not Ruby.
> ... things like [...] HTML [...] even have IETF or W3C specifications nowadays.
HTML was originally designed as an SGML vocabulary [2], and had SGML DTDs by IETF and W3C for the longest time [3] (albeit somewhat defective from the beginning, and grew a number of warts over time).
The beauty of Markdown IMO is that it's specified as a short syntax for HTML, with the option to include inline HTML where the fragment covered by Markdown is insufficient. That's exactly the model supported by SGML's SHORTREF feature which lets you define context-dependent tokens SGML will replace into canonical angle-bracket markup. So if you're looking for a document preparation system that lets you write casual text a la Markdown (or your own customized or novel syntax), then can translate that syntax into predictable markup and goes all the way to support complex document integrations with established XML tool chains, etc. etc. and can also import/produce HTML, then there's always SGML, based on an ISO standard even.
[1]: https://daringfireball.net/projects/markdown/
Re: Thoughts on Markdown
#46I've said it so many times my throat is sore but here goes again... As with literally everything, it depends. Markdown is lovely for tech documentation, notes and journaling. It's simple and beautiful and mostly independent of layout. Want to author something rich and expressive which has a modern web audience in front of it (either end user or editor) and it's probably not the right tool. I work with large numbers o…
> Markdown is lovely for tech documentation
That’s one of the weakest points of Markdown, because it has no support for any sort of cross-referencing so they have to be maintained by hand or through bespoke extension (often conflicting).
Re: Thoughts on Markdown
#47>That’s almost 20 years ago — yikes! What started as a more writer- and reader-friendly syntax for HTML The author appears to have some recency bias that misses the point of Markdown. It didn't start when it was named and mapped to HTML. It was in use on usenet and in emails before HTML even existed. And most of its conventions came from typewriters before that. You could print out a Markdown document today and jump…
> We've had a variety of markup formats including HTML, XML, etc. which are relatively a pain to read or write.
Right, but Markdown relies on HTML (or whatever other markup it is pre-procesing) for anything difficult.
I like Markdown[0] but surely our job as technologists is to find better solutions than a system that requires you to escape asterisks in certain situations, or rely on a preview pane to work out what it will do.
[0] but YAML front matter should burn in the fire
Re: Thoughts on Markdown
#48Those who do not understand history are doomed to repeat it. In the beginning, there was HTML, and it was good. Then "modern content creators" did not "want to learn syntax", created "tools that edited and rendered HTML differently and inconsistently", added hundreds of unnecessary tags in it, then started to get smart about "semantic information" and introduced HTML-5-style tags like , which too few people use... Te…
In the beginning, was runoff. At least runoff was around on DEC machines in 1975. I wrote a couple term papers with it, Markdown is hardly different.
I once typeset an Occam assignment paper in groff, for kicks.
Re: Thoughts on Markdown
#49I agree with a lot in this article. I too have seen 'non-technical' users struggle with Markdown. The popularity of Markdown among developers also reminds me about SSGs (Static Site Generators). Two technologies loved by developers - and no-one else. " For limited use cases, like blog posts of simple rich text with images and links, markdown will get the job done. " I'd argue it's even less suitable than that. Develo…
> Developers never look beyond Markdown when writing documentation or articles and are thus blissly unaware of the much richer writing possibilties of using HTML (which is simple to learn, unlike CSS).
HTML is wolf in sheep's clothing though. It's deceptively simple to learn the basics, but the nested nature of it is something that will allow one to shoot their semantical or representational foot off, even before trying to apply CSS. Take, for example, humble P tag. The thing that trips up most people, for example, is that ideally you'd need to contain text blocks in paragraphs, not just have it free floating in the document. In theory. P tag is simple. Except that end tag is optional. When writing HTML, that is. But not always, as per standard:
"A P element's end tag can be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element."
But in XHTML end tag is always required. And you shouldn't have block level elements like images within P. And you can't nest them. When outputting DIV with a block of text that DIV should contain a P, not just text. DIV's are cool, you can nest DIVs. And they need end tag. Simple? Well:
"Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of more appropriate elements instead of the div element leads to better accessibility for readers and easier maintainability for authors."
But who does that nowadays? It's DIVs all the way down usually. So no, HTML is not simple.
Re: Thoughts on Markdown
#50> If Not Markdown, Then What?
Textile!