Show HN: Wysihtml – Open-source rich text editor for web apps(github.com)
github.com
Show HN: Wysihtml – Open-source rich text editor for web apps
https://github.com/Voog/wysihtml/
45 comments
It can apply classes too as you wish. You can use formatInline or formatBlock command to add inline or block elements with needed classes. An example how its done internally https://github.com/Voog/wysihtml/blob/master/src/commands/fo...
Is there some way to sanitize the output? The prevalence of <br><br> is something I've always disliked about WYSIWYG HTML editors (something a markdown converter doesn't have to struggle with, usually).
I can do paragraphs by not manually breaking lines and instead select the second paragraph's content, then apply the "normal text" style, but this isn't exactly intuitive.
Or one could disallow further linebreaks and thus just create paragraphs when you're entering a linebreak.
I can do paragraphs by not manually breaking lines and instead select the second paragraph's content, then apply the "normal text" style, but this isn't exactly intuitive.
Or one could disallow further linebreaks and thus just create paragraphs when you're entering a linebreak.
Wordpress has had this forever: http://codex.wordpress.org/Function_Reference/wpautop
Like most of WP, the code is ugly, but battle-tested.
Like most of WP, the code is ugly, but battle-tested.
Configuring parser_rules for allowed tags can do a lot, but i think it would not be enough to disable linebreaks alltogether. Thanks for pointing this out. We will consider adding it to configuration.
"Fast and lightweight" is 200ko?
We have so many choices when it comes to WYSIWYG. My favorite is https://github.com/daviferreira/medium-editor.
We have so many choices when it comes to WYSIWYG. My favorite is https://github.com/daviferreira/medium-editor.
Check out FastMail's Squire editor, less than 12k mimicked and compressed - http://blog.fastmail.com/2014/12/08/squire-fastmails-rich-te...
You are right, 200k is not the lightest out there and there is room for improvement. Trying to keep it as light as possible though without sacrifice in functionality like handling nested tables with merged cells etc.
A few feedback points, I suppose...
# Clicking the "no-color" option in the text color-picker doesn't do anything.
# Using the "remove" option on a link inserts a space as well as removing the link, which seems incorrect.
# Using the "remove" option on a link doesn't always remove the entire link. Repro on http://wysihtml.com/ by selecting the word "typewriter", adding a link, then clicking on it again and removing the link. Depending on where you clicked either "type" or "writer" will still be linked.
# Repeatedly toggling tags can get weird. e.g. select a word and keep on clicking the bold/italic/underline button, and note how it'll toggle the tag on, toggle it off, and then just start adding spaces in front of it with every subsequent click.
# Possibly related to the spaces issue, after toggling tags for a bit checking the source generated shows a lot of empty-tags, which is kind of messy.
# Clicking the "no-color" option in the text color-picker doesn't do anything.
# Using the "remove" option on a link inserts a space as well as removing the link, which seems incorrect.
# Using the "remove" option on a link doesn't always remove the entire link. Repro on http://wysihtml.com/ by selecting the word "typewriter", adding a link, then clicking on it again and removing the link. Depending on where you clicked either "type" or "writer" will still be linked.
# Repeatedly toggling tags can get weird. e.g. select a word and keep on clicking the bold/italic/underline button, and note how it'll toggle the tag on, toggle it off, and then just start adding spaces in front of it with every subsequent click.
# Possibly related to the spaces issue, after toggling tags for a bit checking the source generated shows a lot of empty-tags, which is kind of messy.
Apologies for reporting here instead of GitHub Issues. :) Long lines without a break (e.g., space) continue out the side of the box. Firefox 34.0.5.
Thanks for pointing these issues out. Some of them are known to us and rewriting the handling of inline tags is actually in the todo queue already.
They're all really minor issues, but they're also fairly easy to trigger in the initial "I'll play with this to see how it works" phase, which is fairly critical for persuading people to actually decide to use it for their project. :)
> Unifies line-break handling across browsers (hitting enter will create <br> instead of <p> or <div>)
This implies it isn't configurable and unfortunately - in my view this is the incorrect direction to unify in.
Hasn't even MS Word nowadays standardized on Enter=paragraph break, Shift+Enter=line break
This implies it isn't configurable and unfortunately - in my view this is the incorrect direction to unify in.
Hasn't even MS Word nowadays standardized on Enter=paragraph break, Shift+Enter=line break
Shift+Enter is not known very well, at least by my clientelle...
For your rails apps you can use 'wysihtml5-rails' gem.
https://github.com/narkoz/wysihtml5-rails
Author plans to update it to use wysihtml as a drop-in replacement.
https://github.com/narkoz/wysihtml5-rails
Author plans to update it to use wysihtml as a drop-in replacement.
Actually there is a new gem for Rails called "wysihtml-rails" (https://github.com/Voog/wysihtml-rails) that is synced with this library.
FWIW, we've been pretty happy with the Froala Editor: https://editor.froala.com/
Having had the (dis)pleasure of working with TinyMCE on a number of past projects this looks like a no-brainer. The only thing I'm not sure about is the use of `data-wysihtml5-command` attributes to configure the toolbar, is there an option to configure this via a configuration object in JS? - e.g. I just pass the ID of the element I want to use and a set of options?
Currently the toolbar component does not allow this kind of configuration. Probably the easiest to accomplish this currently is to write Your own custom toolbar likehttps://github.com/Voog/wysihtml/blob/master/examples/wotool... or make a pull request that I'll be glad to merge.
Thanks, I'll check it out. PR is always a possibility too :)
What issues did you have with TinyMCE? We recently moved away from wysihtml5 to TinyMCE and have been quite happy with the results thus far.
The latest releases of TinyMCE have been easy to work with, and relatively pain free for us.
The latest releases of TinyMCE have been easy to work with, and relatively pain free for us.
I'm stuck with an old version that I haven't been able to update yet, and it recently started uploading images and documents with full write permissions. The TinyMCE support team tells me that's not possible, but that sure is what it looks like to me.
By my recollection TinyMCE on it's own doesn't do uploading - it's pure client-side code so is incapable of doing so. Are you talking about an official or 3rd party extension or plugin that has a server-side component?
I think it's the official file manager extension that's doing it - though with the old version that I have, the file manager came built in instead of as an optional (paid, now) extension.
There are a lot of commercial options available too; I was reminded of the 'How I reverse-engineered Google Docs' discussion where the author recommended paying $200 for Redactor. Releasing an easily usable full-featured rich text editor is a generous gift!
so timid
Try out their beautiful working app: http://voog.com
Try out their beautiful working app: http://voog.com
Funny, they named their barebones theme after http://en.wikipedia.org/wiki/Pripyat :D. http://voog.com/signup?language_code=en ('Choose' button at the bottom next to the text about the blank slate).
Well, and that city really is just 'bare' and 'bones' :(
Crikey. Site builders are getting frighteningly good. Weebly is already pretty acceptable but at first glance Voog looks like a great leap forward.
This is very cool, I've used the Telerik editor (http://demos.telerik.com/kendo-ui/editor/index) control in the past, but this might be a decent competitor.
Why fork something that is incomplete, unstable, has very limited test coverage, and doesn't tightly control the generated markup?
CKEditor has had the ACF (Advanced Content Filter) for >1.5 years now. It allows you to very tightly control which tags and attributes are allowed.
This feature, and the rest of CKEditor has much, much more test coverage to account for the many browser quirks (notably in contentEditable) that they have had to work around, to prevent regressions. It's a waste of time for everybody to solve the same problems and work around the same browser quirks over and over again.
The "Ability to add uneditable area inside editor text flow (useful when building modules like video tools, advanced image editor etc)." feature is probably the only interesting feature. But it's nothing compared to CKEditor Widgets, which does exactly this, and much more (think storing structured content but transforming it to the specific markup that a frontend developer wants). Just compare Wysihtml's "advanced" demo to the CKEditor Widgets demo: http://docs.ckeditor.com/#!/guide/dev_widgets
See http://docs.ckeditor.com/#!/guide/dev_advanced_content_filte... for more about ACF and http://docs.ckeditor.com/#!/guide/dev_widgets for more about Widgets.
And yes, it's open source: GPL/LGPL/MPL/commercial: http://ckeditor.com/about/license
If we'd collaborate more rather than reinventing the wheel, we'd get so much further. One does not just write a WYSIWYG editor…
CKEditor has had the ACF (Advanced Content Filter) for >1.5 years now. It allows you to very tightly control which tags and attributes are allowed.
This feature, and the rest of CKEditor has much, much more test coverage to account for the many browser quirks (notably in contentEditable) that they have had to work around, to prevent regressions. It's a waste of time for everybody to solve the same problems and work around the same browser quirks over and over again.
The "Ability to add uneditable area inside editor text flow (useful when building modules like video tools, advanced image editor etc)." feature is probably the only interesting feature. But it's nothing compared to CKEditor Widgets, which does exactly this, and much more (think storing structured content but transforming it to the specific markup that a frontend developer wants). Just compare Wysihtml's "advanced" demo to the CKEditor Widgets demo: http://docs.ckeditor.com/#!/guide/dev_widgets
See http://docs.ckeditor.com/#!/guide/dev_advanced_content_filte... for more about ACF and http://docs.ckeditor.com/#!/guide/dev_widgets for more about Widgets.
And yes, it's open source: GPL/LGPL/MPL/commercial: http://ckeditor.com/about/license
If we'd collaborate more rather than reinventing the wheel, we'd get so much further. One does not just write a WYSIWYG editor…
I took part in a hackathon a few weeks ago and we needed a text editor that we could easily implement and customize. In particular, we wanted more control over the appearance of the toolbar -- we wanted to use our own buttons and move them vertically to the left of the text area -- and needed to capture events related to entering text.
We started with CKEditor, found it far too complicated and with a ton of old and unclear documentation floating around, and had to work against its default features to get it scaled back to the minimal editor we wanted. We weren't able to move the buttons to the left-hand side and couldn't style them as easily as we wanted to. Maybe it's buried deep in the docs somewhere but I couldn't tell you, there's a lot there and it's overwhelming for someone who's just getting started and on a time constraint.
Frustrated, we switched to WYSIHTML5 and were able to get exactly what we were looking for very quickly.
I've come to see CKEditor as the WordPress of WYSIWYG text editors: it aims to do ABSOLUTELY EVERYTHING for everyone, but that's not what everyone is looking for. Maybe things would have gone differently if we weren't under the gun but when we were in a pinch, we found WYSIHTML5 to be a much better option.
We started with CKEditor, found it far too complicated and with a ton of old and unclear documentation floating around, and had to work against its default features to get it scaled back to the minimal editor we wanted. We weren't able to move the buttons to the left-hand side and couldn't style them as easily as we wanted to. Maybe it's buried deep in the docs somewhere but I couldn't tell you, there's a lot there and it's overwhelming for someone who's just getting started and on a time constraint.
Frustrated, we switched to WYSIHTML5 and were able to get exactly what we were looking for very quickly.
I've come to see CKEditor as the WordPress of WYSIWYG text editors: it aims to do ABSOLUTELY EVERYTHING for everyone, but that's not what everyone is looking for. Maybe things would have gone differently if we weren't under the gun but when we were in a pinch, we found WYSIHTML5 to be a much better option.
It seems to suffer from tags being left over even after all their content has been deleted. Many editors seem to suffer this too.
Cool.
but why no jquery?
Just asking.
As someone who ported a embedded website away from jquery, it was painful, and I've come to really appreciate it
but why no jquery?
Just asking.
As someone who ported a embedded website away from jquery, it was painful, and I've come to really appreciate it
Firstly jQuery would not help a lot here, as wysiwygs are largely about fixing browser inconsistencies and bugs. You'd like to fix those as close to the source as possible. The other quite big argument is that events triggered in jQuery cannot be seen by other modules correctly. Even not by another jQuery instance. In CMS-es on the other hand you can easily be dealing with many jQuery instances. One on the site itself and another for administration components. Vanilla.js makes things on this scale smaller too.
Having written a wysiwyg editor myself, the bulk of the work in such a project doesn't really touch on what jQuery does.
Assuming you're using contenteditable, a lot of it is about resolving cross-browser differences in the implementation. Probably also reimplementing most of the execCommands since they're wildly inconsistent -- which does involve some DOM manipulation, but is more about using the selection API.
Assuming you're using contenteditable, a lot of it is about resolving cross-browser differences in the implementation. Probably also reimplementing most of the execCommands since they're wildly inconsistent -- which does involve some DOM manipulation, but is more about using the selection API.
I'm really glad they didn't use jQuery.
Note: I am using angular for 90% of my stuff.
Note: I am using angular for 90% of my stuff.
so after I create an html how do I "export" out the html code?
We are trying to revive and modernise a once popular open source editor xing/wysihtml5. It is configurable to be used with and without an iframe. The editable area API is separated from the toolbar so it would be easy to customise or completely rebuild the toolbar logic for your own app.
The Voog team
The Voog team
I glanced through the parser rules, and it looks like you guys have implemented some kind of named filters in addition to the per-tag-per-attribute rule set from wysihtml5.
Having just spent too much time fighting wysihtml5's overly opinionated rules trying to allow <a> tags to allow any value for href, changes in this area are of great interest to me.
Could you touch on what changed in the parser rules?
Having just spent too much time fighting wysihtml5's overly opinionated rules trying to allow <a> tags to allow any value for href, changes in this area are of great interest to me.
Could you touch on what changed in the parser rules?
I will try to update the wiki of our github repo soon with the additional options.
I'm a big fan of WYSIHTML5, really happy to see someone working on this!
Cool!
Looks nice.
Thanks! Been looking for such editor. Will try it out soon.
They'll see a highlighted word or sentence with a bold font, wider spacing and a blue background. So they set the background blue, the font bold and the spacing wider. But really, the editor should provide an intuitive way to apply the <span class="highlight"> element.
Some editors out there do this, but they generally suck in other areas. Wysihtml seems to apply inline CSS. Can it easily apply a class too?