Symphony.

vim? Sorry, couldn't resist.

Did I mention nice looking and easy to use? ;)

What if you create a small extension that, let's say, generates previews on the fly (or an demand). There're some promising javascript based projects out there, if you want to do conversion client side.

https://github.com/jensscherbl/EpicEditor

• First experimental alpha release
• Only tested in Safari so far
• EpicEditor itself is still in alpha and has some issues
• Screenshot attached

Attachments:

Screen Shot 2012-05-03 at 4.42.04 AM.png

Ah, I see

[edit]

Another idea is, instead of doing conversions on the client, is passing the markdown via ajax to a backend page that renders the markup. This way you can retain markdown options set on your field and results should be more reliable.

Not sure if I really get your point. This extension doesn't interfere with text formatters, it just runs on top of markdown enabled textfields and provides additional UI.

Well, you probably have set a markdown mode (markdown, smarty pants, etc.) when you use a markdown enabled textarea, don't you? When you'd let symphony create the html preview (instead of a third party js lib), you can be sure this is 100% representing what's going to be rendered on the frontpage.

It's not meant to be an exact preview of how the content is rendered in the frontend, just providing some visual feedback on its structure.

[Edit]

The different available markdown modes are a valid point, though.

Running the content through Symphony's server-side formatters would be an interesting approach, but I don't think it would be very performant. For example, EpicEditor has a live side-by-side preview in fullscreen mode. Recreating that feature in the way you suggested would require ajax requests and server-side markdown processing on every keyup-event.

That might be a bit overkill.

I really love Henry's inline editor example on the front page. Very nice. I think clients would drool over this implementation.

What if there was a WYSIWYG editor that instead of creating HTML (and showing HTML in the 'view source') it creates Markdown?

The Markdown could be viewed optionally, but the default would show the HTML that would be outputted. This could be like EpicEditor but reversed (with a toolbar).

You'd then be inputting clean markdown into the database, not worrying about unclosed tags, but having the benefit of giving the client something they're used to/comfortable with.

Or is this unworkable?

@heskethm Markdown with instant visual feedback (like iA Writer) would be really cool. Already thought about how to achieve that, but didn't find any ready-to-use libraries.

I guess CodeMirror would be a good starting point to achieve this. maybe we can try and modify the markdown theme to output basic formatting instead of syntax highlighting and hook it up with a toolbar?

I found this Markdown Live which would be a great.

The thing that looks nice with EpicEditor is that you can provide your own CSS for the preview, which means you could show an accurate representation of what the content was going to look like on the frontend.

Different stylesheets could be served depending on the Section context. Could be an interesting project one day if EpicEditor continues to mature

@brendo I especially like the live preview full screen editing. Talked to the guys behind EpicEditor a few days ago. The first alpha which I use in this experimental extension is more of a technical preview and the codebase is under heavy refactoring at the moment in preparation for the first beta (the theming you mentioned is being restructured as well). I will follow the development closely and update my extension accordingly, adding additional options over time where it makes sense.

See the roadmap for further details.

For those who just want to preview what their text looks like from the backend, Preview Textarea adds a “Preview” link that makes an AJAX-powered call to the textarea’s Symphony formatter. You can tweak the styling of the preview by editing preview_textarea.user.css. It’s just a simple way to catch formatting mistakes before saving, but I’m open to suggestions for improvements.

Just came across Aloha Editor too. Looks pretty interesting.

Aloha Editor is a semantic Rich Text Editor framework written in Javascript with best support of xHTML5. You can integrate it in a CMS, blog, wiki software or any other project where you need to edit content with a web based tool.

Looks like a very neat inline editor.

@heskethm Already checked this out a while ago, but it really looks like it's designed for a completely different use case and not really suitable for the Symphony backend.

Amazing! Certainly a useful WYSIWYG HTML5 editor. Maybe someone should make this as an extension.

http://xing.github.com/wysihtml5/

Features

• It's fast and lightweight (smaller than TinyMCE, Aloha, ...)
• Auto-linking of urls as-you-type
• Generates valid and semantic HTML5 markup (even when the content is pasted from MS Word)
• Uses class names instead of inline styles
• Unifies line break handling across browsers
• Uses sandboxed iframes in order to prevent identity theft through XSS
• Speech-input for Chrome
• No jQuery required

wysihtml5 looks promising indeed: light-weight, standards (HTML5) compatible and not dependant on a library such as jQuery (although that's not much of an issue with Symphony).

The one main issue I've found is the way it handles breaks: an enter translates in <br/><br/> instead of <p>. But that is being worked on.

Checked out wysihtml5 already, but it's still too buggy in a lot of ways. Also, I think well-known and widely used projects like TinyMCE or CKEditor will adopt the new HTML5 editing capabilities over time, so if reliable WYSIWYG is really needed, we should focus on improving these extensions instead.

Hey guys and @jensscherbl -

The beta is about done now: https://github.com/OscarGodson/EpicEditor/pull/123

Working in IE9, Chrome, and Firefox and basically just waiting for the other 2 core devs to sign off!

Seriously, massive updates so let us know how you like it. Feel free to pull down the pull request to try it out a little early.