Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with all of this.

I'd also like to note that some parts of Markdown from the user perspective are non-intuitive and clumsy.

Such as links and images (inline).

Markdown works so well because it is intuitive and appeals to those who once saw old word processors. They don't have to worry about syntax, and can just enter their text into a textarea (free from JavaScript WYSIWYG interference and the inherent troubles of running that on old and new mobile phones, their playstation, web browsers, etc)... and it just works.

Yet some parts of markdown are simply not intuitive. Links and images are two places where I see in usability testing that the end user will constantly refer to help documentation to figure out how to do it.

Beyond getting the code consistent, maintainable, and testable I'd love to see the language itself solve some of the papercuts that trouble the lay end user.

Realising that what I was planning to do for my project (discussion forums, tumblr for forums) was to create an alternative to markdown that would resolve some of these user issues as well as parser issues, I had already decided that I would not call it markdown and that I would educate my users in something new that hopefully solves their and my needs and would remain very stable due to a well-thought out and documented design in the first place. If what you're proposing is in this vein then consider my hat thrown in, what help I can give I will... take me to your git repository.



This is sort of my problem with the whole genre of "light" markup formats.... ultimately they are still a bunch of arbitary conventions to remember, and at that point you might as well just learn/write HTML. YMMV.


That's not the problem being solved by Markdown. You don't want to be serving HTML written by users.


Strictly speaking, that isn't the problem being solved by Markdown, either.

Remember that Daring Fireball does not have comments, so this isn't a concern. Markdown was something originally created to solve an authorial problem, not something for forum creators to use for comments.

It's flexible enough to do that, but it isn't the purpose of Markdown.


Why not? You have to protect against malicious HTML injection whether or not the user is using markdown, plain text or html, so why not let them use a carefully restricted subset of html?


While this is not wrong, markdown involves much less typing than HTML. Also, should one need to use HTML, markdown does allow one to switch between HTML and markdown.


They're arguably less arbitrary than HTML; most of them are based in things that people have done/tend to do with plain text when they're trying to create a formatted document. That yields two benefits: the source document is inherently formatted -- transparently so, since even people who don't know what Markdown or the like is will be able to read it -- and creates something of a visual mnemonic for the formatting convention.

Not saying any one implementation is perfect, just that they have these nice properties.


What is your problem with the link syntax? I think it's one of the best bits.


Having wasted a lot of my life reading miles of reddit comments, there are some people who don't understand the link syntax, or switch the brackets ()[]. It happens. But not that often, when the alternate way of posting a link is to just paste it in plain text with no title associated with it.


You have to remember 1) which comes first, url or link text? 2) is it () or []?


I look at it like this: [this] looks a bit like a button you might press (or a link you might click). It looks like what it does.

(this) looks like something you'd whisper off to the side --- to add to the conversation. For example, "That picture is nice (but it needs more trees).".

So links go like: [this is the thing you click](and btw, this is where it leads).


I struggled with that until I looked at it from a parser perspective: links start with [] because () are much more commons in normal language.


There is actually an even easier method.

In normal text, we usually link to things by first citing them then providing the link. An example would be Google (http://www.google.com). Its natural that we surround the link in () in normal text.

Now the bit we add to help the parser is to tell it where the thing we're linking to begins and where it ends. [ and ] are not usually found in normal text and are therefore used for this purpose. Thus the modified example would be [Google](http://www.google.com).


I would much rather see a more mnemonic approach for links, where you would write either _click here_ [http://wherever.com] or _click here_ (http://wherever.com). The underscores look like an underline, which is the traditional appearance of link text in HTML. It's easy to remember. Whether the URL is in square brackets or parentheses (maybe either one would be acceptable as long as they are a matched pair) doesn't matter, but underlining the anchor text is the way to go, IMO.


Beautiful explanation. And one that I can remember while writing in markdown.


I'm just wondering whether a better solution to this is a polite warning in the UI... Did you mean []() instead of ()[]?


I like the wikipedia syntax better for this [url text]. It's much easier to remember.


> It's much easier to remember.

How so?

Markdown has this brilliance in that it's not just random markup that produces html or something output, it's own human-targeted plain text output is its own source. A such the link syntax is extremely easy to remember. When I write text, I want to read the label, whose reference is a link, hence the order is label then link. If I wrote this link in pure plain text I'd simply naturally write:

    Lorem ipsum dolor sit amet (http://www.amet.com), consectetur adipiscing elit.
So the order is the same is markdown since it's its own output. Still the world is not ideal so we need a hint to tokenize a little, and since parentheses surround the link, let's use square brackets. This also fits very well with the array/hash/dictionary syntax, where you associate a key sitting between square brackets with a value.

If I want to make a more remote reference so as not to interrupt the reading flow with a big link (remember that markdown source is its own plain text output) I can simply do what I'd do if I inserted a reference, that is annotate the label.

    Lorem ipsum dolor sit amet[1], consectetur adipiscing elit.
The footer naturally follows, as we again assign a key to a value. And since there can be an optional title to the link, it comes afterwards so that urls vertically align.

    [1]: http://www.amet.com "optional title"
    [2]: http://adispicit.org "optional title"
Again, I find brilliance in Markdown in that it leveraged long (as in decades) established conventions (e.g headers, italics, lists, quotes, code blocks...) that apply directly to plain text in order for the source to be its own output, so that even for someone who doesn't have the first clue about Markdown it's readily readable as if it were not markup.


The problem is that this is a discussion about standardising the Markdown syntax, not changing it.


The fact that Meteor wish to call this Rockdown suggests to me it is to change it.

By creating a specification and tests, they will be modifying Markdown even if just subtly enough to remove bugs and ambiguity. Doing even that is to create something that isn't Markdown, existing Markdown parsers may do something different with the same text... so clearly this isn't Markdown.

It may share 90% (or more, or less) similarity with Markdown, but some areas would certainly need tweaking and changing to make the goal (specification, testability, consistent implementations) possible.

To my understanding this means that Rockdown is Markdown inspired/derived.

And as such, that there is a hope that a good specification and the ability to be implemented in a testable and consistent way... will, by mass use (on the sites mentioned), eventually result in Rockdown superseding Markdown.

In my universe, I'm simply looking to get rid of bbcode as the markup syntax of choice. And if you were at the support end of trying to tell people how to insert images on forums then you'd understand that the Markdown syntax is a real difficulty for a lot of people.

The path that I prefer is to use Markdown, but the areas that cause the greatest difficulty in usability testing, to modify those to make things more implicit and frictionless. Worrying about []() (or vice versa) is an obstacle to the user that shouldn't exist. But if everything else is good from a user perspective then I definitely want to keep that stuff.


Wikipedia also uses markdown. So since there is no standard format for URLs, let's pick a good one.

Also, it could support both of these syntaxes at once - they don't conflict.


I still get those the wrong way around [text url] often enough. I only mess up MarkDown slightly less often because I write more of it.

The "() is more common than [] in regular text, so it makes parsing-sense to start a special markup code with []" is going to help me with that, though. That particular mnemonic only works for coders, though :)

Also, doesn't MediaWiki syntax sometimes also have a pipe | between the url and the text in a link? Or is that only for internal links?


A parser should not be an interactive application.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: