Speaking as someone who has just implemented a similar editor (but only dependent on jQuery) this editor has serious problems. To begin with, the UI does not respond to the selection (what will the bold button do given the current selection?) and using contentEditable DIVs will make 508 compliance horrendous (the selection is lost when a label gains focus). (Our editor allows either divs or iframes, but the latter is pretty much required for solid usability, unfortunately).
The magic is all in execCommand, but you also need to be aware of cross browser issues and execCommand's limitations (e.g. IE won't style using CSS which is a huge pain. ExecCommand can toggle bold but not background color). In the end we use execCommand to create spans and then style the spans.
Nice support for touch styling, speech input, mobile cameras, and dropping images though.
I think that's a bit harsh. First of all, we got it to the point where it's useful for us and shared it. If it's close to what would be useful to you but not 100% there, fork, extend and submit a pull request, that is how opensource works.
I've not tested it in IE because IE is simply not on the critical path for us. That doesn't mean it does not work in IE, I've just not tested it.
After about three months, we looked at usage patterns for MindMup and decided to drop official IE support, as it represents less than 2% of our usage and most people have an alternate browser installed as well.
If IE is on the critical path for you, you could contribute by testing and submitting fixes.
I'll admit it's slightly harsh. But it's probably also true for any sort of mass market web property.
At work I'm currently having to live with supporting IE8+ [1], which I'm looking forward to eventually moving on from. Alas, the traffic isn't there yet. Plus, we're being wary about dropping IE8 since it's the last official IE for Windows XP.
As you say, it's a very site-dependent issue to care about. IE tends to come along with a more mass-market audience. If your site is aimed more at a tech-savvy crowd, you're likely to be able to not care about IE.
Of course, it gets a bit self-reinforcing there! If your early users don't use IE, you might decide that it's safe to drop IE support... and now you'll never get IE users, since they'll just think your site doesn't work.
Interesting random statistic: I have a personal medium-traffic site (about 300k visits / month) aimed at a completely non-technical crowd. IE makes up about 24% of new visits, and has the lowest bounce rate of any browser. Chrome's the single biggest browser, but all the majors are too well represented to not care about supporting.
>At work I'm currently having to live with supporting IE8+ [1], which I'm looking forward to eventually moving on from. Alas, the traffic isn't there yet. Plus, we're being wary about dropping IE8 since it's the last official IE for Windows XP.
If the web property is successful enough, you can ditch IE support and they'll come with something else. Or you'll get new users to replace them eventually.
> If the web property is successful enough, you can ditch IE support and they'll come with something else. Or you'll get new users to replace them eventually.
You're not a business person are you? No manager or CEO is going to take that approach if they can make more money off having some IE users (and a more complex/harder to maintain web app) than no IE users.
I started my first startup while at university undergraduate. And am working on another at the money.
So, yes, I am a business person, just not the "bending backwards" for the customer business person.
>No manager or CEO is going to take that approach if they can make more money off having some IE users (and a more complex/harder to maintain web app) than no IE users
Then those managers:
1) not only do not have any pride in what they are doing (ie. they would put out shit if they could get some more money that way, instead of having a strong opinion on what they want to sell)
2) but also they might be loosing the company money, since they don't seem to understand the notion of opportunity cost.
Sure, they might make X money if the cater to legacy browser users than if they did not. At what overall cost to the company? Some messy workarounds that have your programmers working overtime? Not using nice new technologies that will give you a leg up on the competition? Spending 40% of the companies wages to fix bugs and work around issues for a 10% minority? Not iterating faster, so that in 2 years, when IE8 is < 5%, you have your food eaten by some new company building on stuff that only the latest IE support?
etc etc...
ahhhh the oldest argument on the internet "If you stop supporting their browser, they'll upgrade". no, they won't, they'll just stop using your service and go else where. And yes, this would hurt your bottom line.
>This is, of course, a synonym for "don't bother to use me in anything but hobby projects". (Or stuff which is completely mobile-focused, I suppose.
Huh? Where did you get that impression?
If your service is valuable (instead of, say, just some news site fighting for eyeballs) you can pretty much demand users to use a modern browser.
Even more so, of course, for enterprise and hosted applications, where you can specify what browser the users have to use, take it or leave it. I work on a device front-end that supports all but IE, and it's very liberating -- not to mention no customer ever cared about it enough to complain, they just switched to what he told them to use (and most were using such browsers already).
Also for open source. E.g something like Wordpress (which is used very much professionally) can use it for its admin interface, and require it's users to use a compatible browser -- and nobody will care for the few that don't want to use Chrome/FF/Safari/IE10/Chrome Frame.
With adequately modern browsers being available for Linux/*BSD/etc and XP, and being free, faster, better and more secure, you don't have to have any sympathy for users sticking to old IE versions.
And it's not like you'll be alone in it. I remember when the first web shops started ditching IE6 circa 2008-9 (with a "A list apart" manifesto and everything). That was a huge step forward. And isn't jQuery ditching old IE in version 2.0? Not to mention widely succesful projects like D3 that never supported IE to begin with.
Your service may be valuable, but if it is REQUIRED by someone to do their work then you can't get away with requiring them to change browsers.
>With adequately modern browsers being available for Linux/*BSD/etc and XP, and being free, faster, better and more secure, you don't have to have any sympathy for users sticking to old IE versions.
Sure you do, when you want to have happy users. If even a minority of your users are older/non-technical, asking them to change browsers to view your site (which they may be required to use for work) is a great way to get them to hate the damn application, provided they can even figure out how to change browsers in the first place. It makes complete sense as a designer/anyone concerned about security to force people to update their browsers, but don't forget that to the 60 year old used-to-snail-mail grandma that can totally ruin the experience.
This is the one thing, I wish more people would avoid doing. The fact of the matter is that most people use the browser their computer came with. Getting people to change that is tantamount to saying, we don't need to you as a customer.
> Getting people to change that is tantamount to saying, we don't need to you as a customer.
In many cases supporting legacy IE is more hassle than it is worth, so people genuinely don't need IE8 users as customers.
Unfortunately IE8 came with Widnows 7 so is supported as long as that is which IIRC is until 2020 (for the extended support period). Given how long it took out corporate clients to upgrade from IE6 to IE8 (some only just have) if I don't change jobs I'm going to be supporting IE8 in our applications for the next seven years at least, but many people do have the luxury of being able to say "sorry, I don't have time to be supporting that" especially when they are giving their time/effort for no financial (or similar) gain (I'm at least paid to deal with legacy IE!).
Not gonna be that easy at least for another couple of years. ;)
I will say, most of my stats for clients show some IE10, more IE9 and fewer IE8 these days; about 5%/65%/20% split for IE versions with 10% for older ( IE/other browsers split at about 60%/40% ), and these aren't techy sites either. So there's some good news there.
IE9 Isn't too bad actually, though sadly, a lot of eye-candy projects featured on HN break outright on it or are prevented from loading upon browser detection.
You sound like you know your stuff. This is kinda how I felt too; a small addendum, less is often a good thing, but least is not better. I hope the glitches will get ironed out and will apply to textareas too though. I certainly would rather send a much smaller JS file, especially for mobile users.
Is your editor open source? Any chance you would be willing to share an example as well?
We plan to open source our editor but it's up to the client (who is amenable, just hasn't gone through procedure). Our editor is far more functional, 508 compliant, will be IE8 compatible (argh), and weighs in at about 800loc.
I wrote it rather than use something off the shelf because none of the popular choices have well-behaved UIs.
So ima take the hit of being a stupid person and ask, what's the difference? Why should I use this over bootstrap-wysihtml5 (or why should I use bootstrap-wysihtml5 over this)?
bootstrap-wysihtml5 was a great inspiration. it links in wysihtml5, and gives it a skin. here's a few reasons why we decided to build this one:
- wysihtml5 minimised is 112K + 20k for bootstrap-wysihtml5, without styles and images... this is only 5k, non-minimised.
- we bind hotkeys for common operations automatically (eg cmd+b for bold etc)
- drag&drop for images
- automatically upload images using filereader, not just provide links
- good support for touch devices
- no magic around toolbar, so you can use your own styling
- we don't force an inline iframe which mirrors a text area, which wysihtml5 does
Wysihtml5 has a better support for older browsers, the bootstrap skin has toolbar translations, so I'd still use that if you don't want a custom toolbar or need to support older browsers
I use wysihtml5 in a project. Mainly because all browser rich text editors are waaay to advanced. I don't want people to put images in my text fields, right align the text, put tables there, etc. wysihtml5 gives great control over what can be done. I want some rich editing, but I want full control over it. In my case a few text-types, bold, italic, bullet list and nothing more.
we don't create a toolbar. It's up to you. so if you don't put buttons for that, they won't be able to do it. hotkeys on the keyboard are also configurable, you can just bind certain items so users won't be able to execute the other commands unless they open a javascript console and call doc.executeCommand manually (but then again, that's difficult to prevent for other editors)
What if one copy-pastes in stuff that's not supposed to be there? With wysihtml5 it will clean up based on what's allowed. With yours, I believe I will need to do that manually?
yes, we don't hook anything. i've not tried this, but you should be able to hook on to the paste event for that div (the div is really your markup, we don't do any magic shadow iframing)
5KB is amazing. I thought that this would be a great replacement for bootstrap-wysihtml5 until i saw IE missing from your browsers list.
Btw, for the drag and drop inserting of images. You should probably check the url of the image and if it is from local file storage then upload it to the server and insert the resulting link back. That would be a cool feature to have in a editor.
It looks good, but it's hard to use. They added this whole layer of… sanitization? that strips out all sorts of tags. I'm open to it having been PEBKAC but I recall struggling with it
There's definitely a need for a good bootstrap wysiwig form.
some cleanup might be good, eg when you select everything using cmd+a, then delete, some browser leave a <br/> in the content.
I didn't like forced sanitization in wysihtml5, so we added an optional method .cleanHtml - you can just use the normal jquery html method to get the non sanitized contents, or call cleanHtml() to get trailing empty divs, <br/> and whitespace removed
A couple minutes of basic usage (FF20, Linux) have me in pain:
- CTRL-B (and presumably other shortcuts) doesn't always take effect immediately. Sometimes there is delay, sometimes it seems necessary to let go of CTRL for the event to get flushed, sometimes nothing ever happens at all. Multiple hits without letting go of CTRL also behave erratically.
- Focus stays on formatting buttons and requires manual click to get back to text widget. Several times I wondered where my text was, only to realize focus was on wrong widget.
- By far the worst thing: the way formatting codes are handled leaves me crying for WordPerfect's Reveal Codes. Make some text bold, unbold the text after it, type something right after the bolded text, it isn't bold, hit enter for new line and type something, now it became bold again. Argh!
I like the idea of this, but presently there are some rough edges.
Thanks for reporting this. I didn't test under Linux as I don't have a linux box handy. We bind keyboard events to jquery keydown. Is it better to bind to something else for FF/Linux?
* On Chromium 25 and Chrome 26 the first two issues do not exist.
* More playing with FF20 and it seems this is actually tied to CTRL+B, not any other shortcut. At least initially, clicking the "Bold" button also has no effect. Possible explanation: In FF CTRL+B opens the Bookmarks pane by default, in practice certain focus combinations do open this pane. This explanation would seem to require the Bold widget to be generating a keypress under the hood, though.
* The codes issue is tricky, but one way to see an example on Chrome/chromium browsers is:
1. refresh page
2. select pre-existing "Go ahead..." text
3. type "this is bold and this is not"
4. select "this is bold" and make it bold
5. place cursor at start of " and this is not"
6. type "so is this", text is bold
7. hit enter and type "but this isn't", it isn't bold
The original issue I saw was similar, but related to numbered bullet lists. To reproduce the third issue on FF follow the same steps, except a) one must first mash about on CTRL+B and/or the Bold button until they start working, then follow same steps. Result: you get the inverse, text in 6 is not bold, and text in 7 is.
Sorry, don't have domain knowledge about keybinding.
I was able to reproduce the first two problems in FF on Linux, but not Chrome (everything seems to work perfectly there). It seems to be FF's problem, not Linux's.
Firefox on OSX works fine... so it's a combination. I don't have a linux box handy to test, but it would be nice if you could see if keydown is the problem, and if so we'll change it.
Was really thrilled at first, this could be exactly the kind of wysiwyg-editor I've been looking for. Unfortunately it seems the markup returned by .cleanHtml() is completely useless (see http://pastebin.com/uwpSMKsi). If I could get proper markup (paragraphs, headlines, not a thousand divs) and maybe the possibility to edit the markup myself this would be the perfect editor.
You can make it create paragraphs and headings by adding a button for the formatBlock command to your toolbar. Google for execCommand, all those things are supported out of the box.
Now that seems to be along the lines of what I'm looking for. The only problem I can see is that I'm working on an open source project, and your licenses doesn't seem to be compatible with that.
I'm not currently doing development on the software myself so I don't know the file size for sure at this moment; however, I believe it's similar to Redactor which is known for its small size (not sure if it's more or less now because we've just cut more size off of our deliverable).
As for number of files, I believe it is 1 Javascript file. The required HTML and CSS is compiled into the JS now to reduce number of files to transfer. I don't know how many images it is right now but if it is more than 1, then we will likely eventually compile it down to 1.
Thanks for the info! I have been looking at redactor for nwzPaper, but I will take a look at snap editor now. Currently using jwysiwyg and the format stripping is garbage. It's super light and the license doesn't cause us any problems, so I have stayed with it until I can commit to a better LT solution.
Very slick and great filesize. I've been working on a wysiwyg document editor and am very tempted to use this. My only problem is with contenteditable in general, which is hard to convince to use <p>'s. I'm rolling my own paste function and optimistic about getting the functionality you have, but definitely not in 5k ;)
Also, do you have any idea of a resource for valid/invalid nesting rules for inline and block elements? I'm currently sanitizing to keep block elements at the top level.
I realize your rolling your own, but if you are interested in an available editor, we have SnapEditor which does exactly that.
One of the core features is that it keeps the nesting of blocks and tables consistent. All P, H1, H2, etc. tags are always at the top level. If they are not (for example, after a Paste), we automatically fix the HTML so that it is. In this way, you always have consistent, predictable, HTML which makes it easy to style and reason about.
It also works both as a form-based editor (traditional) or an inline editor (like Aloha editor).
It's nice, but I'm more of a fan of direct inline editing on the web page via HTML5 contenteditable=true. The Aloha Editor http://aloha-editor.org does this very well. I've actually just recently added their editor to my node.js mini cms, called ContentBlocks http://contentblocks.herokuapp.com
this does exactly that, sets a div to contenteditable=true, but also binds hotkeys for common operations, extends with toolbar support, provides filereader for drag&drop.
I'm curious about the voice-input feature. In your example, it's activated by clicking the microphone - but could a website activate this without a click (or by tricking a user into clicking something they thought was performing some other function)? Providing the ability to listen in and capture the audio from a user's location without any prompt seems like a huge potential security issue to me.
no, this is an input field with chrome speech enabled (<input type="text" x-webkit-speech>). The microphone icon you see is the right part of that field, and the text is transparent. We've done it like that because at the moment only input fields support speech input in chrome, and we couldn't find a way to activate programatically.
There is no onclick event on that part, it's just part of the text field.
Interesting. I'd known Chrome supported Voice input - just never tried it like this. For anyone wishing to disable this in your browser, the Chrome Extension TamperMonkey allows you to install UserScripts easily, and the UserScript named "Disable HTML5 Voice Search" on userscripts.org programmatically disables any voice-input controls on the pages you visit.
Is anyone aware of a bootstrap based wysiwyg editor that also supports tables? So many cool editors omit this, but it's one of the most common rich text tools people want in business applications.
I've not tried this, but I believe this would come down to creating a button that calls insertHtml with the basic table strucure, and calling enableInlineTableEditing before that.
How is the performance on iPad? Do you guys do full strength testing on iPad etc.? It would be great if it can be optimized for other device browser as well. Good job. Keep it coming.
for ipad and iphone, the toolbar has to move down otherwise the screen jumps around all the time. this isn't part of the widget as we wanted to keep styling out, but you can see it in action by going to http://www.mindmup.com , selecting any node and clicking on the paperclip icon in the tools menu (or on desktop pressing A on the keyboard).
We move the box to the top of the screen and resize it so that a mobile keyboard can fit in, also moving the toolbar to the bottom.
Cool. Lately I have been involved in customizing/implementing features in text editors for one of my project and have solved some of the problems specifically for iPad. Hopefully I can contribute to this project. Thanks for making it open source. Good work.
raw.github.com serves js files with text/plain as the mimetype and a 'X-Content-Type-Options: nosniff' header, which prevents Chrome from executing it.
can you give me a bit more info on "can't"? Did you try drag & drop or toolbar? what file type have you tried? We have a filter on content type in the editor, so only things read with content type image/* are inserted.
Perhaps this is too strict?
re "code" button, this would be trivial to implement but doesn't really belong in the widget. Just get the html out using jquery (it's your element) and show that instead of the element by passing through a formatter (or just jquery.text())
Sorry for the lousy bug report, I hate when it happens to me. Neither drag n drop nor clicking on the "insert image" button displayed the image on the textbox. Tried both jpg and png. Works in Chrome and Firefox.
Yes, I know it should only take a few lines of code, but it's something I usually take for granted in a wysiwyg editor.
could you check what content type the filereader reports when you upload from safari? I've just tried again with safari on OSX and it seems to work. perhaps I should detect the extension, not just content type...
The magic is all in execCommand, but you also need to be aware of cross browser issues and execCommand's limitations (e.g. IE won't style using CSS which is a huge pain. ExecCommand can toggle bold but not background color). In the end we use execCommand to create spans and then style the spans.
Nice support for touch styling, speech input, mobile cameras, and dropping images though.