Hacker News new | past | comments | ask | show | jobs | submit login
Our tiny jQuery/Bootstrap rich text editor is now open-source (mindmup.github.io)
241 points by gojko on Apr 7, 2013 | hide | past | web | favorite | 86 comments



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.


They got around the IE stuff by saying "Requires a modern browser (tested in Chrome 26, Firefox 19, Safari 6)".

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.)


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.

[1] http://help.deviantart.com/38/


>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.


>You're not a business person are you?

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...


But if you stopped supporting those ie8 users would it detract from your bottom line? By breaking old browsers you push those people to upgrade.


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.


Citation needed.

I, for one, have switched tools (including browsers) several times to be compatible with stuff and services I care about.


>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.


>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.

Actually that's when you can absolutely getting away with requiring them to change browser!

Except if you meant to write "UNLESS if it is required by someone to do their job".


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.

FWIW, it does work OK so far on IE10 for me.


> 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!).


>The fact of the matter is that most people use the browser their computer came with.

No, they don't. Else it would be 90% IE.

Most people use Chrome and Firefox. And there are places in Europe where IE is almost non existent.

And even on the Mac, Chrome and Firefox users are as many or equal to Safari users.

So "most users stick to the browser the computer came with"?

Might have been true back in Windows XP days. Not for a long while.


IE10 is pretty solid. I only wish that I could get away with supporting just it, instead of IE8+.


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.


Biggest site I've got access to analytics on gets me 10/9/8 at 18%/56%/19%. So, someday!


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.


This looks nearly identical to http://jhollingworth.github.io/bootstrap-wysihtml5/

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.

Does your editor allow this kind of control?


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)


Thanks for your replies. :)


The lack of an iframe on yours is the killer feature for me (long story, but can't use an iframe for what I'd want this for). Great job all-around!


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's not tested in IE, but we don't use any browserbspecific code (apart from chrome speech) so it might work just fine.

For server uploads, this would be pretty easy as a callback.


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


But does it work?

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?


More testing:

* 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.


To be fair, that's contenteditable's behavior, not this plugin's.


Oh. I didn't know that. That's bad news :( Guess I have to keep dreaming about a wysiwyg that actually works.


We have an editor, SnapEditor, (http://www.snapeditor.com/) and it will keep your HTML clean. You will get the output you expected.

You can even cut and paste from Microsoft Word or Google Docs and it will fix your HTML to the way you'd expect.

Sunny


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.


What's the unminified size of the editor files and how many files are you down to for a completed page load? Thx!


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.

Sunny


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.

Daniel


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).

Sunny


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.


FYI, the toolbar buttons change size on hover, it's a little distracting. It looks like they're getting thicker borders on the sides.


ok. one of the key things about the widget is that it doesn't impose styling on you, so you can use whatever you want for the toolbar.

I'll look into why the demo bootstrap style is doing that.


It's also doing it on the http://www.mindmup.com/ homepage. 0.o


i'll look into that as well :) thanks


Hi gojko, I believe if if you change this:

$('a[title]').tooltip();

to this:

$('a[title]').tooltip({container:'body'});

that little size-stuttering effect will be fixed.


thanks, it seems that's done the trick. I've republished the page


Looks pretty cool. One thing I don't get tho: How does the image upload work? Does it just base64 encode it and use inline images?


Inlines a data url using FileReader


Minor editorial nit: "Boostrap" (sic) is misspelled on the front page. Thanks for putting it up, though!


:( thanks for letting me know, I've fixed it


I really miss the ability to resize, move images. Every time try to move image, the chrome tab crashes.


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.

We just pass calls to execCommand, anything that's supported with that should work out of the box https://developer.mozilla.org/en/docs/Rich-Text_Editing_in_M...


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.


fantastic. i'm looking forward to your pull requests :)


I'm wondering why a file upload dialog opens up when I click in the empty area beside the 'redo' button in the demo (FF 19). Is it just me?


Hotlinking raw.github.com assets has a rate limit. The demo is not working properly (apparently because of jquery.hotkeys.js).


I've replaced the hotlink, hopefully the new page will be up soon


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.


Looks like this could be really useful, nice work. Unfortunately I'm not having any luck entering text on my iOS6 iPhone.


[deleted]


http://codemirror.net/ is a very pleasant way to set up code editing text areas.


Looks nice, can't insert images with desktop Safari though (ML, latest).

Will it have a “code“ button (check generated HTML)?


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...


Although I like the idea of these, I'm far too paranoid to allow any user to use them.


well we kind of need this to provide rich text editor for node attachments... This is how you can see it in action

http://blog.mindmup.com/p/working-with-attachments.html


Was able to complicate the styling by getting bold that I couldn't unbold anymore.


not bootstrap-based but I found [redactor](http://imperavi.com/redactor/) really good. It's not free to use though.


I'm having trouble with the bold button




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: