Live data from Hacker News

Thoughts on Markdown

smashingmagazine.com

101–110 of 167 posts

Re: Thoughts on Markdown

#101

Earlier quoted context omitted.

Gopher would not and could not have won, for two very good reasons: (Would not) -- it was more complex to implement, being stateful (and it lacked the markup flexibility of HTML, which was kind of a big draw) (Could not) -- the University of Minnesota announced their intention to collect licensing fees on their Gopher server (and client, I think), which was invented there. This was a key moment in the web's developme…

Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;) Netscape Navigator handling images was also a Big Deal(tm). Of course, there could have been a graphical (X) gopher client that showed images, but just like the people who like gopher and gemini now dislike images, I suspect it was the same then (think of the bandwidth!) It's hard to convey how intensely cool it fel…

> Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;)

It's not so much at the creation -- it's several years in (four years in for HTML/HTTP). Though it is about when I became aware of it.

What I recall of the time is that the web was just becoming a point of research interest, and big firms had product R+D interest.

Like I say, I can't find anything to prove my recollection now -- so it could well be wholly unreliable! -- but my specific recollection from damn year 29 years ago is that IBM's response (and likely the response of others) to the Gopher server licence situation was to seek clarification from CERN over their intentions with the web. IBM also had patents (concerning hypermedia) that were relevant but were never asserted.

It would always have been Tim Berners-Lee's intention to not assert patents but CERN obviously was his employer.

> It's hard to convey how intensely cool it felt

Were you in that same workstation lab in Reading, then? Seriously, you had to wear a coat and scarf if you were in one corner...

Re: Thoughts on Markdown

#102

Earlier quoted context omitted.

> 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 i…

Why would we think there is a better solution? There's only so many symbols on the keyboard. There's only so many symbols in ASCII. That's how you end up having to escape things. An asterisk literal usually belongs inside single or triple backticks IMO, and you won't have to escape it there.

Right, but then you have to explain to end-users why they need to escape an asterisk, or why they have to have their content on screen twice -- once in source and once in frustratingly flickering preview.

Personally I think it is our job as web developers not to encourage this for end users.

(Unless those end users are writing a book, in which case, definitely. Markdown as a source for Pandoc is fabulously better than a wordprocessor)

Re: Thoughts on Markdown

#103
post #88

Earlier quoted context omitted.

> 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 i…

what's worse: (a) a preview pane, or (b) a bloated editor (msWord) or mysterious web format (google docs) also, there's many WYSIWYG editors that do an awesome job (Typora, Zettlr, etc)

I really like Typora as it goes, I've used it myself, and I've begun to recommend it to people who are writing long-form documentation or books (because I like pandoc a lot).

I have not used Zettlr but I will look at it; thanks for the recommendation.

But I still think Markdown has little place in content management systems for end-users; it's obtuse.

Re: Thoughts on Markdown

#104
post #39

The discussion reminds me a little of the one around LaTeX in the scientific community. Latex is extremely powerful but reading the raw source of a text is a pain. WISYWIG is just so much more comfortable when writing, but MS Word sucks in its own specific and manifold ways (as does LibreOffice). HTML is still not nice to read, too much boilerplate tags required. Markdown source however is mostly well-readable in a p…

> Latex is extremely powerful but reading the raw source of a text is a pain. For the kind of text that you'd use Markdown for, i.e. text that is mostly just text and not math heavy, LaTeX should be almost as readable as Markdown. For example, \section{Introduction} is almost as readable as ## Introduction

Takes a bit more typing though unless you some macros dedicated to it.

Not hard to do but Markdown is easy to write anywhere.

Re: Thoughts on Markdown

#105
post #73

>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…

The author is also a Sanity employee and, while I like the ideas behind the Sanity CMS, if you ever create a schema with an RTF field, you'll see the opposite extreme when you read the text back via GraphQL. If Markdown was created to make the source readable, Sanity exists to make content unreadable (via expansive nested JSON for even simple tags like ). It's pretty easy for a paragraph of text to take 200 lines of…

> Like Sanity, this author has expanded three paragraphs of content into 600 lines of text.

*snort* this is mischievous but funny.

Re: Thoughts on Markdown

#106
post #88

Earlier quoted context omitted.

what's worse: (a) a preview pane, or (b) a bloated editor (msWord) or mysterious web format (google docs) also, there's many WYSIWYG editors that do an awesome job (Typora, Zettlr, etc)

I really like Typora as it goes, I've used it myself, and I've begun to recommend it to people who are writing long-form documentation or books (because I like pandoc a lot). I have not used Zettlr but I will look at it; thanks for the recommendation. But I still think Markdown has little place in content management systems for end-users; it's obtuse.

fair point; outside of it's main use case (writing documents), we're better offer using more sophisticated tools

Re: Thoughts on Markdown

#107

Earlier quoted context omitted.

Why would we think there is a better solution? There's only so many symbols on the keyboard. There's only so many symbols in ASCII. That's how you end up having to escape things. An asterisk literal usually belongs inside single or triple backticks IMO, and you won't have to escape it there.

Right, but then you have to explain to end-users why they need to escape an asterisk, or why they have to have their content on screen twice -- once in source and once in frustratingly flickering preview. Personally I think it is our job as web developers not to encourage this for end users. (Unless those end users are writing a book, in which case, definitely. Markdown as a source for Pandoc is fabulously better tha…

Users can avoid having to escape the asterisk by using Microsoft Word.

It seems to me that you expect some perfect solution to exist, and it is this solution that technologists should make it their mission to find.

I think there is no perfect solution and we should navigate the trade-offs holistically, rather than focusing on a single imperfection like suboptimal asterisks.

Re: Thoughts on Markdown

#108

Earlier quoted context omitted.

Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;) Netscape Navigator handling images was also a Big Deal(tm). Of course, there could have been a graphical (X) gopher client that showed images, but just like the people who like gopher and gemini now dislike images, I suspect it was the same then (think of the bandwidth!) It's hard to convey how intensely cool it fel…

> Thanks a lot for expanding. I had no idea IBM was present at the creation, like some spirit of evil ;) It's not so much at the creation -- it's several years in (four years in for HTML/HTTP). Though it is about when I became aware of it. What I recall of the time is that the web was just becoming a point of research interest, and big firms had product R+D interest. Like I say, I can't find anything to prove my reco…

No, it was a lab in Stockolm filled with Sparcstations…

Re: Thoughts on Markdown

#109
post #73

>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…

The author is also a Sanity employee and, while I like the ideas behind the Sanity CMS, if you ever create a schema with an RTF field, you'll see the opposite extreme when you read the text back via GraphQL. If Markdown was created to make the source readable, Sanity exists to make content unreadable (via expansive nested JSON for even simple tags like ). It's pretty easy for a paragraph of text to take 200 lines of…

I share with the author of the article the need for a standard format for presentation-independent structured multimedia content, and that html+js+css is now too complex for this purpose.

But I think that such a format should keep rich text separate from structure, in the same way that CSS keeps style separate from content. Content structure in a web environment is inherently complex, so there should be a standardized way to link markdown-style simple "pages" that have linear or shallow tree structures, to build the superstructure of a complete web site.

In my opinion that lack of a specific format for structure is what is limiting the growth of common tools for rich content. Wikis are the only example I know of an attempt to create such a format, but it works by having basically no structure, just uniquely named pages and hyperlinks between them.

Re: Thoughts on Markdown

#110
post #38

Markdown 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…

John Gruber’s original markdown processor was written in Perl, not Ruby.

I never knew :-). Perl was already a bit obscure by the time I got active in the late nineties. But it makes sense as the first wikis would probably have been implemented in that rather than in Ruby. Likewise, php would have happened later.
Post reply on HN