Our tiny jQuery/Bootstrap rich text editor is now open-source
mindmup.github.io
mindmup.github.io
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.
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'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.
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.
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...
I, for one, have switched tools (including browsers) several times to be compatible with stuff and services I care about.
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.
>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.
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".
FWIW, it does work OK so far on IE10 for me.
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!).
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.
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.
Is your editor open source? Any chance you would be willing to share an example as well?
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)?
- 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
Does your editor allow this kind of control?
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.
For server uploads, this would be pretty easy as a callback.
There's definitely a need for a good bootstrap wysiwig form.
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.
* 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
Sorry, don't have domain knowledge about keybinding.
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
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
Daniel
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.
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
There is no onclick event on that part, it's just part of the text field.
I'll look into why the demo bootstrap style is doing that.
$('a[title]').tooltip();
to this:
$('a[title]').tooltip({container:'body'});
that little size-stuttering effect will be fixed.
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...
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.
Will it have a “code“ button (check generated HTML)?
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())
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.
Deleted comment