Rich Text vs. Markdown
Hi –
I am curious why you are using Markdown syntax instead of using standard rich text format.
Markdown has its disadvantages: You have to learn a special syntax without a nice GUI and without shortcuts -- not very user friendly. I think there a many users who aren't get used to writing Markdown. It is a mess while printing, too -- and you are having no plans to improve this behavior.
Implementing Rich Text Format on the other hand should be a relatively simple and safe solution using the Apple TextEngine framework. Advantage is a fool proof usage that anybody who use a Mac is used to work with.
Well, it seems you made a decision to prefer Markdown over RTF. Can you please share your arguments, why?
1Password Version: 7b11
Extension Version: 4.3.1
OS Version: Mac OS X 10.12.6
Sync Type: local sync / WLAN
Comments
-
There is no restriction saying we can’t build out a GUI that’ll work with the markdown we’ve implemented. I’m not sure I see any technical difference between markdown and RTF in this regard. Likewise printing wouldn’t inherently be any better with RTF. Even with RTF we’d need to spend time updating the printing framework if we wanted to print formatted text.
As for why markdown over RTF... well, we like markdown. Most of the tools we use take advantage of markdown formatting. Also markdown is inherently human readible, whereas RTF is not. I’m not sure there is much more to it than that, but I’ll see if anyone else on the team might have further insight and want to chime in.
Ben
0 -
@Holgerr, there was some discussion of different text formats. The principle appeal of Markdown is what @Ben said, that it is human readable in its raw format.
I, being the oddball in the group, argued for text/enriched (RFC 1896). text/enriched is not to be confused with rich text format, application/rtf. Back in the earliest days of the Browser Wars in the 1990s, there were people who felt that HTML was too unrestricted to be used in email. We fought a losing battle against HTML mail. But merely saying "no" to HTML mail wasn't going to go anywhere unless there was an alternative on the table that did much of what people wanted (at the time) without the problems we foresaw with HTML email. So text/enriched was invented. (I was not involved in its invention, but I was an advocate for it and an opponent of HTML in email). text/enriched It is strictly parsable with a deterministic context-free parser, includes no remote content, very explicitly is not extensible, and us ultimate a text format.
Well, as know we lost. Email with HTML and ActiveX was not going to go away, despite all of the privacy and security issues that have very predictably plagued us since.
What Markdown and text/enriched format have in common in that they are inherently text. They can be read and edited without the need of a specific application. RTF cannot be. And if we stick to a subset of Markdown and sanitize any internal HTML, then we can get a degree of security that is, at least, easier to analyze than RTF. There is more room for an RTF parser to break in insecure ways than a restricted version of Markdown.
One reason that we went with Markdown instead of text/enriched is first because everyone just looked at me and said, "what are going on about here? What the heck is text/enriched?" Well, that is how I like to tell the story. The real reason is that I could not provide pointers to good text/enriched handling libraries for all of the platforms on which we need to support it.
So that's me. Spoiling everyone's fun for decades!
0 -
From experience being a Mac consultant, I can tell you most users will not use Markdown. If it takes more than a couple of minutes to learn, they aren't willing to go there.
"well, we like markdown" is a bad answer. You should write for your users not for your team.
0 -
Thanks for your detailed answer, @jpgoldberg and @Ben . From a users view it makes no different, how you name the text engine: HTML, RTF, enriched, markdown, TeX… I understand, that you are looking for a solution that works on Mac, Windows and Linux (some day).
Best solution would be, if the user doesn't need to know, how things work – they just have to work. Take the comment fields in this forum: They have nice little icons on top to make selected words bold, italic, build some lists and so on, Select some text, apply formatting. Bingo, you're done. Text enriched with styles should look like the same, whether you’re in edit mode or in rendered mode. That's the way, text editors are used to work. And IMHO that's the way they’re expect to work.
And here I have to agree with @Dianeoforegon : I don't want to fiddle around in some source text, learn markdown syntax, have to save to preview, edit again, oops mistype a syntax, save, edit, okay looks a little more right, save – you got the idea. I don't want to work with raw text files, I want to work with text as it is. WYSIWYG – a thing and a concept that have made the Mac great once upon a time. That’s why Mac users depends on a nice GUI to get things done. Generally and historically speaking ;-)
0 -
@Dianeoforegon You've taken one small portion of my reply and taken it out of context. :)
The points regarding WYSIWYG or some form of GUI are well taken, and as I mentioned using markdown on the backend doesn't prevent us from building something like that in the future.
Markdown, specifically, has been requested a number of times.
Choosing markdown gives us the ability to have something functional now, whereas building something that necessitates a GUI would've pushed back the release of any form of rich text. With this we've satisfied a number of requests, while also leaving open the possibility of future expansion of the feature.
Ben
0 -
Would it not be fair to say that your concern is not with the choice of markdown as the markup, but that there is no GUI and keyboard shortcuts for formatting? Both of those things could be implemented on top of the currently available markdown feature set.
Ben
0
