It is much more lightweight than tinymce.
But seems to miss some things like pre, tables and text direction.
I would invite you all to test it, and see if might work better than tinymce.
About support for markdown entry.
I really would like people to be able to switch between markdown and html editing.
This because I have some customers who have very different editing needs in the same team, and I am sure some would prefer markdown and other the html editor.
Mixing that will give much confusion in the editor teams (which are located across the globe).
For a good support we need to have Markdown to HTML and HTML to Markdown conversion support.
Where just editing in one should keep that one format as well.
That means that either we need to make the HTML to Markdown conversion foolproof or need an extra intermediate form with both representations.
Both add considerable complexity.
An intermediate representation could be:
-record(editabletext, { type :: atom(), raw :: binary(), html :: binary() }).
Where the type can be, for example, 'markdown'.
We need to support this intermediate form in the same places where we support translations (that are {trans. } tuples) right now.
> It is much more lightweight than tinymce. > But seems to miss some things like pre, tables and text direction.
> I would invite you all to test it, and see if might work better than > tinymce.
> About support for markdown entry.
> I really would like people to be able to switch between markdown and html > editing. > This because I have some customers who have very different editing needs > in the same team, and I am sure some would prefer markdown and other the > html editor. > Mixing that will give much confusion in the editor teams (which are > located across the globe).
> For a good support we need to have Markdown to HTML and HTML to Markdown > conversion support. > Where just editing in one should keep that one format as well.
> That means that either we need to make the HTML to Markdown conversion > foolproof or need an extra intermediate form with both representations.
> Both add considerable complexity.
> An intermediate representation could be:
> -record(editabletext, { type :: atom(), raw :: binary(), html :: > binary() }).
> Where the type can be, for example, 'markdown'.
> We need to support this intermediate form in the same places where we > support translations (that are {trans. } tuples) right now.
> It is much more lightweight than tinymce. > But seems to miss some things like pre, tables and text direction.
> I would invite you all to test it, and see if might work better than > tinymce.
> About support for markdown entry.
> I really would like people to be able to switch between markdown and html > editing. > This because I have some customers who have very different editing needs > in the same team, and I am sure some would prefer markdown and other the > html editor. > Mixing that will give much confusion in the editor teams (which are > located across the globe).
> For a good support we need to have Markdown to HTML and HTML to Markdown > conversion support. > Where just editing in one should keep that one format as well.
> That means that either we need to make the HTML to Markdown conversion > foolproof or need an extra intermediate form with both representations.
> Both add considerable complexity.
> An intermediate representation could be:
> -record(editabletext, { type :: atom(), raw :: binary(), html :: > binary() }).
> Where the type can be, for example, 'markdown'.
> We need to support this intermediate form in the same places where we > support translations (that are {trans. } tuples) right now.
> It is much more lightweight than tinymce. > But seems to miss some things like pre, tables and text direction.
> I would invite you all to test it, and see if might work better than tinymce.
> About support for markdown entry.
> I really would like people to be able to switch between markdown and html editing. > This because I have some customers who have very different editing needs in the same team, and I am sure some would prefer markdown and other the html editor. > Mixing that will give much confusion in the editor teams (which are located across the globe).
> For a good support we need to have Markdown to HTML and HTML to Markdown conversion support. > Where just editing in one should keep that one format as well.
> That means that either we need to make the HTML to Markdown conversion foolproof or need an extra intermediate form with both representations.
> Both add considerable complexity.
> An intermediate representation could be:
> -record(editabletext, { type :: atom(), raw :: binary(), html :: binary() }).
> Where the type can be, for example, 'markdown'.
> We need to support this intermediate form in the same places where we support translations (that are {trans. } tuples) right now.
I'm not sure about the licensing, I didn't look into it that far.
I've found another really impressive editor called Divshot (http://divshot.com). It would be great to be able to design a page in the backend by using an editor similar to this. You could define a bunch of edit/view templates that become drag n drop components for building up the layout of the page whilst your editing the content. You could also save a layout as a template for future use ;)
>> It is much more lightweight than tinymce. >> But seems to miss some things like pre, tables and text direction.
>> I would invite you all to test it, and see if might work better than >> tinymce.
>> About support for markdown entry.
>> I really would like people to be able to switch between markdown and html >> editing. >> This because I have some customers who have very different editing needs >> in the same team, and I am sure some would prefer markdown and other the >> html editor. >> Mixing that will give much confusion in the editor teams (which are >> located across the globe).
>> For a good support we need to have Markdown to HTML and HTML to Markdown >> conversion support. >> Where just editing in one should keep that one format as well.
>> That means that either we need to make the HTML to Markdown conversion >> foolproof or need an extra intermediate form with both representations.
>> Both add considerable complexity.
>> An intermediate representation could be:
>> -record(editabletext, { type :: atom(), raw :: binary(), html :: >> binary() }).
>> Where the type can be, for example, 'markdown'.
>> We need to support this intermediate form in the same places where we >> support translations (that are {trans. } tuples) right now.
> I'm not sure about the licensing, I didn't look into it that far.
> I've found another really impressive editor called Divshot (http://divshot.com). It would be great to be able to design a page in the backend by using an editor similar to this. You could define a bunch of edit/view templates that become drag n drop components for building up the layout of the page whilst your editing the content. You could also save a layout as a template for future use ;)
> Cheers
> Tom
> On Monday, October 15, 2012 9:40:12 AM UTC+1, Marc Worrell wrote:
> Hi Tom,
> That editor is very nice indeed!
> I like the highlighting and how it advances.
> Didn't work on my phone, but I guess that is more layout/css problems than architectural.
> I can't find any license in the GitHub repo on this one.
> Do you know more about it?
>> It is much more lightweight than tinymce. >> But seems to miss some things like pre, tables and text direction.
>> I would invite you all to test it, and see if might work better than tinymce.
>> About support for markdown entry.
>> I really would like people to be able to switch between markdown and html editing. >> This because I have some customers who have very different editing needs in the same team, and I am sure some would prefer markdown and other the html editor. >> Mixing that will give much confusion in the editor teams (which are located across the globe).
>> For a good support we need to have Markdown to HTML and HTML to Markdown conversion support. >> Where just editing in one should keep that one format as well.
>> That means that either we need to make the HTML to Markdown conversion foolproof or need an extra intermediate form with both representations.
>> Both add considerable complexity.
>> An intermediate representation could be:
>> -record(editabletext, { type :: atom(), raw :: binary(), html :: binary() }).
>> Where the type can be, for example, 'markdown'.
>> We need to support this intermediate form in the same places where we support translations (that are {trans. } tuples) right now.
