In particular, there are some screenshots which show table editing, insertion of images, and what appears to be navigation and forms as well. My favourite, though, is on page 37, where it looks like some user-defined paragraph classes ("info" and "alert") have been included in the formatting toolbar -- it looks _really_ slick!
There's at least one other project which is trying to make editing web content better: http://www.wymeditor.org/
I recall reading that, due to the way that WYMeditor makes the HTML structure explicity (while still keeping it relatively end-user-friendly), it tends to encourage users to produce "nice" HTML -- simply because poorly-structured HTML looks ugly in WYMeditor. :)
But wow, Aloha looks absolutely beautiful! The sooner FCKeditor and tinyMCE die, the better off we'll all be.
CKEditor and TinyMCE have solved a very difficult problem in extremely elegant ways; their developers deserve more respect than wishing their projects death.
Both of those editors rely on the contentEditable support of the browser to power the actual editing, and browsers have traditionally done a very poor job at producing valid HTML. They make attempts at "post-validation" and "attribute scrubbing", but these are at best makeup on a gorilla. I certainly wouldn't call their solutions elegant.
Having worked on numerous content management systems in the past, one of our biggest issues was trying to "lock down" the WYSIWYG editor so as to minimize the chances that clients could inadvertently break the layout when editing. It was a huge pain point for us, and I lost count of the number of times I had to go in and fix broken pages.
I'm very glad to see that the state of the art in HTML editing is moving forward, and it's well past time for CKEditor and TinyMCE to be put to pasture, IMHO.
Same problem here: the one feature that all these editors lack is the ability to restrict what kind of formatting that the users can create.
In a system I've created for a client, some users are allowed to use e.g. bold and italic, but most users aren't (because they would go overboard and make every other word bold). Post-scrubbing the edited html often breaks the editing experience, and browsers have lot's of bugs in contenteditable.
Hi all,
we try to address this issues (bugs of the browsers and functionally to restrict to defined formatting) with Aloha Editor. For ex. we have more than 80 unit tests for the ENTER button. One of those is hitting the ENTER in a H1 Tag.
The current is a release in an early development state and we want to focus on reliability and basic functionality (be able to write without errors) in first step.
On the insert tab, all I see is Table, but I can't seem to find inserting images, editing hyperlinks, bullet points.
Also, Firefox keeps asking me if I want to kill an unresponsive script, so wondering what that is...
And what is the aGPL? If I include a link to the js file on my webapp, do I have to open source all my code? I really don't get what all these different licenses mean.
AGPL's a version of the GPL that considers "running a modified version as a webapp" equivalent to what counts as "distribution" with the normal GPL. The goal is that if, say, Amazon AGPL'd their EC2 infrastructure, and you created an improved version that you then put online as your own cloud provider, you'd have to release your improvements. The normal GPL wouldn't require that, because running a service off code isn't considered "distribution" of the code (the code itself never leaves your servers). People who use the AGPL, though, want semantics roughly equivalent to what the GPL got you with fat-client apps: if someone made and sold a modified version of your GPL'd offline word processor, for example, they'd have to GPL the modifications.
Not sure it makes any difference with .js code, though, because in that case the code is being distributed, so the normal GPL would already apply.
I'd also like clarification on this. I think I remember the AGPL pissing off the ExtJS community quite a bit. From the discussion though, all it meant is that the javascript code you write to extend the library has to also be AGPL'ed. But if you bundle it with an open source app, it can be MIT, and you can still use it on top of a closed source web site.
Just like if one library cross references another GPL library, it doesnt automatically make that library GPL also. No code sharing is happening, just runtime dependencies.
But please let me know if I'm way off base here...
Much of the functionality they mention can be done with other Editors. We've used edit-in-place for the past several years, even with things like CKEditor. There's nothing that forces you to need to do a page-reload to load CKEditor or other editors, rather you need an omniscient wrapper that can deal with it. For example, we use edit-in-place all the time with CKEditor, but of course we created a NOLOH wrapper for it.
From there, it's easy to create an Edit-In-Place object using CKEditor: http://noloh.diffpaste.com/#/667/, then wherever you would like edit-in-place functionality you simply instantiate an EditRegion.
Hi asnyder,
the difference between Aloha Editor and others is, that you can make any element in the HTML DOM like H1-H6, DIVs, P, SPAN, etc. directly editable.
I like the idea, but you can't even insert a link with the editor. I assume it is just an oversight because it would make perfect sense to have an insert link button right next to the insert table button. Kind of a large omission though, especially if you are claiming HTML WYSIWYG. (And what about images?)
Hi timmfin,
you are right. We don’t have a working link example yet. This is because of the concept we’d like to follow editing content. We don’t want to handle link’s as special elements. A link is A tag but the rest is like any other tag in a HTML document with the need to edit the SRC attribute. It also makes sense to enable Users to edit other elements like ABBR, CITE, etc. and a lot more specially when it comes to semantic annotation of content. Therefore we want to put a special attention to the editing of attributes like the SRC attribute of the A tag. I hope we can come up with that soon.
The same thing when it comes to insert any image or even other resources like automatic list from databases, slideshows, flash videos and the more. We are experimenting with a “block” concept which enables the user to insert non editable blocks like the above and handle their content. Still you will need to write an plugin to the resource source of your choice.
Hmm. Not particularly impressive thus far. Here were my first two impressions:
- Tried the link last night several times, and the server never responded.
- Tried again today, it came up, I selected some text and clicked "Heading". The whole document turned bold. Hit Ctrl+Z and nothing happened.
Left.
Stuff like this is all about first impressions. These guys managed to screw that up for me twice. It's like Joel Spolsky said about premature exposure: "Now you've got two problems: your thing sucks, and everybody knows it."
@1 thanks you for your feedback with the server. Actually we have a problem with the backup in the night (MEZ) on the server we cannot solve easily. I’ll have to switch to another host with the website.
@2 Heading works on the paragraph and makes a H1-6 element around the paragraph. This behavior is like in MS Word if you did not select 1 or more characters. The resulting style depends on the CSS. Maybe our demos do not point that out clearly. You should have a look at the resulting source code after some formatting.
And yes, we still have some problems. Specially with tables. But I think it’s better to give others a chance to review and feedback in an early stage so we can react on the feedback. Thank you.
In particular, there are some screenshots which show table editing, insertion of images, and what appears to be navigation and forms as well. My favourite, though, is on page 37, where it looks like some user-defined paragraph classes ("info" and "alert") have been included in the formatting toolbar -- it looks _really_ slick!
There's at least one other project which is trying to make editing web content better: http://www.wymeditor.org/
I recall reading that, due to the way that WYMeditor makes the HTML structure explicity (while still keeping it relatively end-user-friendly), it tends to encourage users to produce "nice" HTML -- simply because poorly-structured HTML looks ugly in WYMeditor. :)
But wow, Aloha looks absolutely beautiful! The sooner FCKeditor and tinyMCE die, the better off we'll all be.