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