Highlighted some text in the middle of the paragraph. Attempted to change formatting to "H2". The entire paragraph became "H2", and in the text below the "##" ended up on the line above the paragraph, which I don't think is valid Markdown. To be fair, this is an edge-case. Maybe don't show header formatting as an option in the middle of a block of text?
- Tooltips! I didn't know what the bullet list button was until I pressed it.
- Selecting text in the middle of a paragraph and choosing a header type or pre or blockquote affects the whole paragraph. This isn't immediately intuitive. I don't have a good solution to this, but it's something to consider.
- Once I select text in the middle of a paragraph and mark it as pre there doesn't seem to be a way to back out this change, selecting blockquote just embeds a blockquote in the pre block. Note, this may have happened because I selected different blocks of text within the paragraph for each change, but since it affects the entire paragraph it makes sense for this to not matter.
[update] The <= and => icons are not intuitive as undo/redo. I thought that they were for indentation before I hit them. Also note that I backed out all of my changes, yet still ended up with a <pre> surrounding the text at the bottom, even though it clearly wasn't there in the WYSIWYG at the top. Adding <pre> to the paragraph again didn't cause a double-<pre> down below though.
Selecting text in the middle of a paragraph and choosing a header type or pre or blockquote affects the whole paragraph. This isn't immediately intuitive. I don't have a good solution to this, but it's something to consider.
Yeah, this is what browsers do by default when issuing commands to the contentEditable. The way to fix this would be to recognize the command before it issued and splitting the text before and after a selection to their own block-level elements.
Once I select text in the middle of a paragraph and mark it as pre there doesn't seem to be a way to back out this change, selecting blockquote just embeds a blockquote in the pre block.
Yeah, pre is kind of difficult to handle. I'm thinking about solutions. Previous Hallo didn't have pre enabled to work around this, but I really would like to be able to add code snippets when I write.
The <= and => icons are not intuitive as undo/redo.
The actual undo/redo implementation comes from the browser, so it is a bit hard to do much about it. But whenever we get to doing OT with ShareJS there might come a better way to handle editing history.
This is cool -- I've been looking for something like this. There seems to be some "jank", at least on firefox -- I think the result of it wanting to be taller than my window (on a 1920x1200 screen). Sometimes when I hint enter, the whole screen jumps up and down, I think related to scrolling.
Hm tested it on chrome and it seems to scroll correctly. The black window "stops" at the bottom of the page, whereas on firefox (possibly with non-default font settings), it is trying to go below the bottom of the window.
I would like to use markdown in the contenteditable area too. I expect it to recognize that I mean bold when I write jooo -- otherwise I would be stuck using the GUI buttons every time I want to change something.
That is a long-wanted feature in Hallo, not only when producing Markdown, but also when Rich Text Editing normal HTML. Would be great for power users.
I want something like this quite badly. However, I'm not sure this is suitable for the users who I want this for (ie, people who don't need to understand markdown formatting)
1. Doing an html to markdown conversion, as you seem to be doing, feels like a giant hack. And one with leaky abstractions to boot (Hit enter off the end of a list, and you get <div></div> inserted into the markdown source).
2. Link editing is super important, and, also a very difficult problem (selection/range management issues) without the html to markdown problem added on top.
I think something like this is doable by having the transformation only happen one way (from markdown to html), given a markdown parser with full access to the parse tree. However, there's many other issues that would arise from doing it that way.
I probably didn't explain that well. There are plenty of non wysiwig markdown editors out there. The appeal of this demo is that you're editing the markdown source through a wysiwyg editor. However, with this demo, there are two authoritative sources of content, the html in the contenteditable, and the markdown. I'm arguing that there should only be a single authoritative source of content; and I'd like that to be markdown. I think it's possible, though difficult.
You could treat the HTML version as temporary and Markdown as "master". I was considering to do the demo that way - having the original source in the Markdown textarea, and generating the HTML from it before loading the editor.
No, I don't think it was supposed to free us from wysiwyg the way you mean. The real purpose of Markdown was creating a markup language that can be easily read and understood by humans and rendered like HTML. It's an HTML replacement for some use cases. When it's been parsed and rendered its easy to read and when you look at it as plain text it's still easy to read (not to mention write) even by people not familiar with code whatsoever.
Imagine you build a simple website for someone and allow them to edit it. You could give them a WYSIWYG editor with formatting buttons but those editors usually override some of your styles and produce messy code. Or you can give them this Markdown WYSIWYG editor and in most cases it's easier to be sure it won't override your styles and keeps the focus on content. I love that idea. I've had lots of success with teaching very non-tech savvy people markdown in 5 minutes flat. And since most markdown converters I know produce very minimal clean HTML i can be sure my styles won't be overridden. Compare that to something like Wordpress' editor which produces all sorts of sloppy, obsolete code riddled with spans and stuff that overrides my CSS and this is awesome!
So what I'm saying is that Markdown isn't just for text editors. It's for anything that requires the final product to be nicely formatted and the raw code to still he human readable. One of my current hobby projects is an online notes app that automatically converts your writing to Markdown if you use it and I love it. (https://writeapp.me - shameless plug for sure)
Boring: It just shows the rendered markdown next to the raw markdown. More interesting would be a solution that uses the same space to show the rendered form and for user input. E.g. as you type "cool" the asterisks disappear and instead you see the italicized word.
Not WYSIWYG: What-you-see-is-what-you-get means you visually present to the user all the options available. The user should not have to happen to know a set of magic incantations. Markdown requires magic incantations. Some users know them, many users do not. If you want to eliminate toolbar buttons, do something like iOS where when you highlight a word you get hovering format buttons.
Oh, never mind. I was confused, I thought I was suppose to type in the raw Markdown source area and didn't realize that the rendered markdown area was the editor. Sorry.
Yeah, the floating toolbar like iOS. Cool stuff. I won't know if it's really useable for me until I try writing one of my reports in it. (One of my team's tools uses Markdown to generate emailed reports. It can be painful sometimes.)
In the same vein, I recently started using EtchJS to do lightweight WYSIWYG editing. It doesn't do Markdown, just HTML, but it's very simple and straightforward, and takes advantage of the contentEditable property to be lightweight. It's also designed to be used with BackboneJS.