There's no caveat. It says "Redactor распространяется бесплатно по лицензии MIT или GPL, на ваш выбор." which literally means "Redactor is distributed freely under the MIT or GPL licenses - it's your choice."
Edit: This goes to the lack of English docs, not to your misunderstanding I'm sure.
Looking at this again 3 days later, it seems the license has been changed again. The license is now the "Creative Commons Attribution-NonCommercial 3.0 license.", and they're charging for commercial use.
Yep, Aloha is very cool, especially now that they're replacing ExtJS with jQuery UI to make it lighter. It is unfortunate that they've stuck with the problematic AGPL, though.
It differs from GPL in that it is "viral" also when served through the web, so it could mean that your whole web application must either be AGPL, or you must buy an exception from the developer.
AGPL is a new license, and so there are few examples of how it affects things in practice. Many developers (especially ones building open source under less-strict license) prefer to keep their distance.
Not to mention that there is no way to know how a viral license even works when dealing with a non-linked language like Javascript or HTML.
The goal of the AGPL was to keep people from modifying GPL programs that were essential on the backend, but then keep their modifications hidden. With the normal GPL, if you don't distribute a binary, you don't have to release your code. With the AGPL, the goal was to force people to also release backend code. But code licenses start to get very shaky when we aren't talking about binary-linked modules.
I'm a big fan of Aloha. I can't wait for them to get extjs out of the system. That, combined with the fact that they include their own copy of jquery (just in case you don't have it loaded) makes the payload beyond crazy for a wysiwyg editor. If you use it, I highly suggest compiling your own minified version that does not include jquery. That will at least get the size down some, at least until the move to jquery ui is complete. Just keep in mind the license whenever you do anything with it. I'm still not convinced anyone understands how AGPL applies to publicly available js.
I disagree. The size of the typical webpage is growing at faster rate than people are upgrading to faster internet connections. The average webpage is now > 1MB. It matters because adding even a tenth of a second to your load time can cost you in pageviews and revenue.
There's a reason why W3C didn't just replace <b> and <i> with <strong> and <em>. A lot of people think they're just equivalent, but a lot of other people disagree. "Please display this in italic" arguably sends a different message from "Please emphasize this", and in some settings they may not be interchangeable.
The classic example is screen readers. A phrase that’s italicized because it’s important should probably be slightly louder, but a phrase that’s italicized because it’s foreign should probably be pronounced slightly slower. Those are entirely orthogonal things, and it’s useful to distinguish them.
Semantic HTML + CSS can be taken too far, but having separate layers gives you a lot more flexibility than presentational HTML alone, which tends to be very brittle.
If <i> means something different from <em>, you can keep them distinct while keeping everything "semantic". In fact, you could have a dozen different HTML elements for each use case of italics, e.g. <foreign> for foreign words and <t> for titles of books and movies, and it will be a mess, but it will still be "semantic". So the semantic-vs-presentational argument doesn't even apply here.
Meanwhile, the whole concept of using italics for emphasis is a Western idea. CJK languages, for example, don't use italics for emphasis, and most of their italic fonts actually look terrible on screen.
In HTML5, <i> and <b> now have the deliberately vague semantic definitions of "alternate voice" and "stylistically offset" – this could cover emphasis, book/film names, key words, foreign phrases, etc. Incorrect use of the more specific semantic tags (eg. generating <em> when the user sets a film title to "italic") is worse than a lack of semantic detail.
HTML5 was designed with the understanding that not all web content can be authored by someone who knows the correct use of semantic HTML tags like <cite>, <em>, <strong>, <mark>, etc. Application-level copy can use those tags, but a rich text editor (for normal people) can't know which one is appropriate, so it should always default to the vague ones, <b> and <i>.
I just added bootstrap-wysihtml5 to a project and I'm liking it. My only problem is it won't let me type comments in the HTML view and I can't figure out how to dynamically resize the text area. Redactor seems to let you do this. Looking forward to trying this out as well.
Edit: Redactor looks like it retains formatting for the HTML. That's enough to make me switch.
It deserve it's fantastic qualifier. It's the first wysiwyg editor I test that works correctly with iPad. Excellent work.
I would love to make it simpler to insert iPad images. Basically make the upload intermediate step not visible. Unfortunately it is not possible to upload images from the iPad.
edit: unfortunately copy past doesn't work on iPad. The selection is difficult and the copy is simply ignored. Past inserts whatever is in the clipboard.
It is the copy operation from inside the editor text area that doesn't work.
If you copy text in another place, it gets stored in the clipboard and the past operation works as expected. If you copy text selected in the editor text area, the clipboard is left unchanged. Pasting gives you whatever was in the clipboard.
So trying to copy text from the editor text area and pasting it in another app or place doesn't work since it's the copy operation that doesn't work.
The text selection is also not working as expected since it behaves slightly differently than other iPad text editable text field. But this is not a real problem.
It most certainly works in the provided example from the article, the same way as in other text editors on iPad. We might have different versions (builtin browser in news:yc on iOS 5.1.1).
I had two issues: you have to click on the top of an empty textarea to start editing (guessing the first input position), and text entry stopped working after pressing the bold button.
I don't like the fact that when I resize the editor the content disappears until I complete the resize. During the resize (click on the tab at the bottom and drag), the content disappears.
Looks nice, but I was unable to stretch the image back to its original size after shrinking it. It kind of inches a little bit and then stops. It's irritating to see the page announce itself as "fantastic" when it's clearly not properly finished.
Interesting. It's seem to be the issue with capturing mouse events. If you move the mouse out of the image quickly, it'll lose it and the resize will stop. But if you move the mouse slowly so that it always stays over the image, it'll resize it. It's a workaround to use for now (but sure, it's a problem with the implementation).
Great work, really nice to use. Would love to see this as a WordPress plugin (sick of the default editor) but that would require plugin support, as per the roadmap.
These are terrifically hard to make, and I applaud anyone who take the time and effort.
But, a problem: Tapping Bold with no text highlighted (the expectation is that whatever you type next is bold) not only doesn’t work, but steals focus and you lose your cursor
You should not consider this library production-ready!
This is ok... although there are lots of better alternatives. Some issues:
- No way of adding headings? * edit: sorry it's under styles.
- Clicking bold, italic etc should expand the selection to the word that the cursor is in.
- Setting formatting should restore the cursor to the editing area
- Clicking into a formatted area should toggle the buttons in the toolbar that apply
- image alignment a little clunky. Why not add a simple overlay for align centre|left|right on mouseover?
On the plus side image resizing is done well.
One thing that annoys me no end is that all editors I've ever used apply block level formatting (h1,2,3 etc) for an entire paragraph when only a sentence is selected. The most intuitive approach would be to break the sentence out of the paragraph and style only it. As a user I expect what I have highlighted to change not all of the surrounding text as well!
These things aren't easy to get right, especially cross browser. I recently put together an editor to exactly suit my needs (uses contenteditable instead of an iframe), but it's chrome, firefox and ie9+(? i think) only. Trying to get something usable across legacy browsers is ridiculously hard.
Can anyone recommend an editor with a really good API for making custom buttons? My admittedly shallow research hasn't uncovered anything that is particularly joyful to use.
92 comments
[ 3.2 ms ] story [ 170 ms ] threadsome confusion on licenses - MIT is available but with a caveat and I don't think you can do that.
Edit: This goes to the lack of English docs, not to your misunderstanding I'm sure.
That was the primary reason that made me start http://hallojs.org
AGPL is a new license, and so there are few examples of how it affects things in practice. Many developers (especially ones building open source under less-strict license) prefer to keep their distance.
The goal of the AGPL was to keep people from modifying GPL programs that were essential on the backend, but then keep their modifications hidden. With the normal GPL, if you don't distribute a binary, you don't have to release your code. With the AGPL, the goal was to force people to also release backend code. But code licenses start to get very shaky when we aren't talking about binary-linked modules.
This seems really promising at first. Would love to try it soon but it really needs a public repo. English documentation would be a great plus too! :)
https://github.com/Pita/etherpad-lite
On the other hand, full-screen mode is really cool.
I have a fairly typical internet connection, and I can download 40 MEGABYTES in about 8 seconds.
Shouldn't it be <strong></strong> ?
Semantic HTML + CSS can be taken too far, but having separate layers gives you a lot more flexibility than presentational HTML alone, which tends to be very brittle.
Meanwhile, the whole concept of using italics for emphasis is a Western idea. CJK languages, for example, don't use italics for emphasis, and most of their italic fonts actually look terrible on screen.
In HTML5, <i> and <b> now have the deliberately vague semantic definitions of "alternate voice" and "stylistically offset" – this could cover emphasis, book/film names, key words, foreign phrases, etc. Incorrect use of the more specific semantic tags (eg. generating <em> when the user sets a film title to "italic") is worse than a lack of semantic detail.
HTML5 was designed with the understanding that not all web content can be authored by someone who knows the correct use of semantic HTML tags like <cite>, <em>, <strong>, <mark>, etc. Application-level copy can use those tags, but a rich text editor (for normal people) can't know which one is appropriate, so it should always default to the vague ones, <b> and <i>.
2. Because it doesn't use inline styles
3. Because it produces valid html5 markup
4. Because it's proven end tested in Basecamp Next
5. Because it's made by Xing
Full disclosure, I'm the primary author.
Edit: Redactor looks like it retains formatting for the HTML. That's enough to make me switch.
I would love to make it simpler to insert iPad images. Basically make the upload intermediate step not visible. Unfortunately it is not possible to upload images from the iPad.
edit: unfortunately copy past doesn't work on iPad. The selection is difficult and the copy is simply ignored. Past inserts whatever is in the clipboard.
If you copy text in another place, it gets stored in the clipboard and the past operation works as expected. If you copy text selected in the editor text area, the clipboard is left unchanged. Pasting gives you whatever was in the clipboard.
So trying to copy text from the editor text area and pasting it in another app or place doesn't work since it's the copy operation that doesn't work.
The text selection is also not working as expected since it behaves slightly differently than other iPad text editable text field. But this is not a real problem.
But, a problem: Tapping Bold with no text highlighted (the expectation is that whatever you type next is bold) not only doesn’t work, but steals focus and you lose your cursor
You should not consider this library production-ready!
Surely you kid, this is the nicest one I am to see come out yet. File a bug mate.
- No way of adding headings? * edit: sorry it's under styles.
- Clicking bold, italic etc should expand the selection to the word that the cursor is in.
- Setting formatting should restore the cursor to the editing area
- Clicking into a formatted area should toggle the buttons in the toolbar that apply
- image alignment a little clunky. Why not add a simple overlay for align centre|left|right on mouseover?
On the plus side image resizing is done well.
One thing that annoys me no end is that all editors I've ever used apply block level formatting (h1,2,3 etc) for an entire paragraph when only a sentence is selected. The most intuitive approach would be to break the sentence out of the paragraph and style only it. As a user I expect what I have highlighted to change not all of the surrounding text as well!
These things aren't easy to get right, especially cross browser. I recently put together an editor to exactly suit my needs (uses contenteditable instead of an iframe), but it's chrome, firefox and ie9+(? i think) only. Trying to get something usable across legacy browsers is ridiculously hard.