Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond Markdown (2018)

johnmacfarlane.net

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Beyond Markdown (2018)

#101

Post by rollcat »

drawkbox wrote: post #66
sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

> IMO, because it does not have a well-defined spec. Same reason that JSON won. JSON and Markdown are base standards that were generated by market need to simplify. JSON won because it was not overly complex and there was some flexibility. If you need more go YAML or use JSON as a platform for more. Every attempt to change JSON has and should be shot down. JSON really just has basic CS types: string, int/number, bool…

> Every attempt to change JSON has and should be shot down.

I really wish JSON allowed for final trailing commas in arrays/objects.

It would make for more readable diffs, simpler text templating, easier writing/parsing for us humans, etc. I'd happily trade all of TOML, YAML, XML, and every other similar format in existence for that one change.

Re: Beyond Markdown (2018)

#102

Post by mort96 »

blooalien wrote: post #58
doubleunplussed wrote: post #38

Earlier quoted context omitted.

And in markdown you chuck them between backticks to indicate they're verbatim text to be rendered in monospace.

> "And in markdown you chuck them between backticks to indicate they're verbatim text to be rendered in monospace." Only if the intent is for the URL to be copy/pasted, otherwise you enclose the URL in or [text](url) to make it clickable.

Most markdown implementations make URLs clickable without the angle brackets.

Re: Beyond Markdown (2018)

#103

Post by toastal »

oneeyedpigeon wrote: post #86
toastal wrote: post #68

Earlier quoted context omitted.

> keyword bullet lists You mean a definition list like the HTML native one?

I'm sure they mean DLs, yes - this is the one thing I always bemoan that markdown lacks, even more so than tables.

### But my headings

* can be a definition list

* if I don’t actually care about semantics

Re: Beyond Markdown (2018)

#104

Post by FinnKuhn »

SoftTalker wrote: post #34
jitl wrote: post #23

Earlier quoted context omitted.

But I like to write paths like /usr/bin/ in my text and don’t want to worry about backtick code quoting them every time

Most people don't write file paths. Only a concern for programmers, who should be fine escaping them by whatever mechanism.

no, but most people definitely use links in their texts and they have the same problem. / is also regularly used for fractions or/and in a situation where you could use two words

Re: Beyond Markdown (2018)

#105

Post by jillesvangurp »

sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

You are completely right. The underlying theme here is that the requirements matter.

The requirement for Markdown is to be simple and easy. It's intended for use by people who are going to ignore whatever specs and documentation there are. They'll write a little comment, a bug ticket, or a readme and they might need things like links, bold, italic, etc. And the job is to turn that into some legible HTML. So most of its features are simple and easy to remember. Just add a blank line for a new paragraph, prefix your bullets with a -. and so on.

Markdown is undeniably simple and easy to learn. Which is why it got so popular. It has edge cases but they don't really matter. It has obscure features (e.g. tables) most people don't use, so those don't matter either. And there's a wide range of things it can't do that also don't matter. The job never was being a drop in replacement for more complex tools. It was removing the need to use those for the simple use cases and be simply good enough.

The alternatives each chase requirements that are important to their creators but not to most casual users, or indeed the people that integrate markup tools. And of course the more these alternatives differ from Markdown, the harder of a sell it becomes. And the more there are, the less likely it is for any of them to become more popular than markdown. At this point, markdown is a common default in things like issue trackers, readme's on Github/Gitlab, etc. Any tool integrating some kind of markup language support in their content management is more likely to be using markdown than anything else at this point.

The reason is simply that using something else breaks the principle of the least amount of surprise for the user. Markdown is the largest common denominator. It's good enough and easy enough to deal with. So, most new things would favor using that over anything else. It's a self re-enforcing thing.

Re: Beyond Markdown (2018)

#106

Post by H8crilA »

This makes parsing and rendering easier, but writing harder. Given the widespread adoption of Markdown I suspect this project to go absolutely nowhere, since it focuses on precisely the opposite thing that makes Markdown popular.

Re: Beyond Markdown (2018)

#107

Post by Unknawnuser »

holler wrote: post #65

> Consider, for example *this* text* Oh yes. I made the fun decision to write a markdown parser/contenteditable component for https://sqwok.im and ended up spending probably a month on it, largely writing endless unit tests and covering odd cases like that. It's far from perfect and probably will still break on certain ambiguous inputs. I like his ideas for clarifying the language for the most general audience.

[flagged]

Re: Beyond Markdown (2018)

#108

Post by silvestrov »

One feature which I'm missing which is very useful for CMS systems etc is a standard syntax for implementation specific callbacks/macros.

E.g. a macro that returns todays date, todays great offer, etc. Or a "number of days until xxx" for countdowns until some event.

His attribute syntax is very close. A posssible macro syntax use {@ as leading marker, e.g.

    {@macroname position=left}
or

    There is {@daysuntil date=20230710} days to launch.

Re: Beyond Markdown (2018)

#110

Post by billyhoffman »

drawkbox wrote: post #66
sqs wrote: post #2

I understand where the author is coming from and respect their contributions to Commonmark. But... There are tons of markup languages for prose that have well-defined specs. So, why did Markdown win? IMO, because it does not have a well-defined spec. It is highly tolerant of formatting errors, inconsistencies, etc. If an author makes a mistake when writing Markdown, you can always look at it in plain text. Whereas a…

> IMO, because it does not have a well-defined spec. Same reason that JSON won. JSON and Markdown are base standards that were generated by market need to simplify. JSON won because it was not overly complex and there was some flexibility. If you need more go YAML or use JSON as a platform for more. Every attempt to change JSON has and should be shot down. JSON really just has basic CS types: string, int/number, bool…

JSON won because parsing it on in the browser was just was a call to “eval()”, and then you just access the object using normal JS conventions/syntax (e.g data.foo[0].bar). Whereas XML required creating a DOM parser and document fragment, and then using cumbersome HTML DOM methods like “ getElementsByTagName()” to get each value directly (or worse Xpath). It totally sucked.

Native support for JSON parsing and stringify helped when it came later. The Selector api that also came later made XML parsing a little easier if you didn’t want to use XPath, but by then most things were JSON anyway.

Post reply on HN