Show HN: WYSIWYG-editing Markdown with Hallo Editor(bergie.github.com)
bergie.github.com
Show HN: WYSIWYG-editing Markdown with Hallo Editor
http://bergie.github.com/hallo/markdown.html
12 comments
Tooltips!
Good point! Done: https://github.com/bergie/hallo/commit/259c6172e475188f01fd9...
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.
https://github.com/bergie/hallo/issues/54
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.
I'm using FontAwesome, and they will hopefully add a proper undo at some point (https://github.com/FortAwesome/Font-Awesome/issues/16).
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.
Good point! Done: https://github.com/bergie/hallo/commit/259c6172e475188f01fd9...
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.
https://github.com/bergie/hallo/issues/54
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.
I'm using FontAwesome, and they will hopefully add a proper undo at some point (https://github.com/FortAwesome/Font-Awesome/issues/16).
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.
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.
Very nice!
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.
It might be complicated to do (ex: I have entered the left but not right yet...), but it might also be simple; just watch the contenteditable area and pass it through some basic REs.
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.
It might be complicated to do (ex: I have entered the left but not right yet...), but it might also be simple; just watch the contenteditable area and pass it through some basic REs.
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.
Feel free to add comments to: https://github.com/bergie/hallo/issues/11
(we're having an IKS hack week in Saarbrucken now, and Hallo is one of the focus areas. So something might actually happen around this)
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.
Feel free to add comments to: https://github.com/bergie/hallo/issues/11
(we're having an IKS hack week in Saarbrucken now, and Hallo is one of the focus areas. So something might actually happen around this)
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.
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 thought the whole appeal would be the fact that it's WYSIWYG. Wouldn't a one way md-to-html transformation preclude that?
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.
You mean like a WYSIWYG editor for markdown?
There's pagedown which is used on Stackoverflow.
There's pagedown which is used on Stackoverflow.
I don't get it. Markdown was supposed to liberate us from WYSIWYG and let us work in our text editors.
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)
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's not WYSIWYG at all.
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.
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.)
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[1] 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.
[1] http://etchjs.com/
[1] http://etchjs.com/
EtchJS is pretty cool! I'm actually mentioning it in the Create README: https://github.com/bergie/create#readme (see "Similar projects")
It would be interesting to see whether we could collaborate on some widgets that could work on both.
It would be interesting to see whether we could collaborate on some widgets that could work on both.
Here's a WYSIWYG (md-to-html only though) plugin for Vim, if that's your preferred workflow: https://github.com/suan/vim-instant-markdown It uses Github README styling too
(Disclaimer: I wrote it)
(Disclaimer: I wrote it)
Hmm, there seems no way to add hyperlinks to the WYSIWYG portion and if I enter one in the Markdown field, I just get bold text…
Yep, Hallo has a link plugin but I didn't have time to convert it to the new Bootstrap-styled UI that I landed today.
You can see a more fully-featured configuration of Hallo in these screencasts: http://blog.iks-project.eu/semantic-enhanced-cmf-editor-now-...
You can see a more fully-featured configuration of Hallo in these screencasts: http://blog.iks-project.eu/semantic-enhanced-cmf-editor-now-...
Reminds me of Aaron Swartz's https://www.jottit.com/
That's nice ... is it supposed to do something when I select the text, though? Chrome/Ubuntu
Yeah, you're supposed to see a toolbar: https://github.com/bergie/hallo/issues/50#issuecomment-47170...
Other suggestions:
- 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.