Live data from Hacker News

Aloha Editor - HTML5 WYSIWYG Editor

aloha-editor.org

21–30 of 40 posts

Re: Aloha Editor - HTML5 WYSIWYG Editor

#21
post #16
post #6

Earlier quoted context omitted.

Just drag'n'drop an image from your desktop into the page. At least it worked for me ;)

Well, yes, it works, but there isn't an upload process, so I thought the image is linked to your local drive-- which is useless. In closer inspection, the image gets transformed to a base64 encoding (data:image/gif;base64,[...]) which is useless in this context.

With the new HTML5 file upload feature, there's the possibility that you don't see the upload process (although it may be not the best way to do it for bigger images).

Also, they're still working at the image plugin, so I think it will be improved.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#23
this seems interesting but I feel like it might not necessarily replace things like tinymce and ckeditor. this seems to blur the lines between the text you're editing and the page you're on, which can be nice for certain things, but for certain blogs and CMSs people might want a more traditional "here is the edit box: the text you type in here is what's going to appear on your blog/page/whatever" text editor.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#25
post #20

Pretty slick--have to say I enjoyed the big mouse cursor coming up and editing the top paragraph, that was rather clever. In trying the demos, it behaved rather unobtrusively and flexibly, and despite looking a little like Word's contextual ribbon it didn't make me want to set anything on fire after a few minutes. That's a first for an in-browser rich text editor. I think it's interesting that "old" rich text editors…

TinyMCE has a ribbon theme that seems to work with the latest TinyMCE version,

http://tinymce.swis.nl/

Re: Aloha Editor - HTML5 WYSIWYG Editor

#26
After many years, the sad truth is that wysywig editors are only as useful as the output generated when users copy and paste from word documents, which is what I have found the vast majority of input from actual end users to be.

Not supporting wysywig is a tactical advantage in my book.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#27

"Sorry your browser is not supported at this time" Really Opera, a modern html5 compatible browser "is not supported"?

Aloha Editor as well as Opera did improve since Aug 2010. At that time Aloha Editor v0.9.3 and Opera 10 did not work properly together. I did some debugging and improvements with Maike Tylor from Opera. The current dev version of Aloha Editor has the bad alert replaced with a console.log and Opera 11 offers better support for contentEditable. Due to the huge refactoring and at the same time major improvements and extensions the dev is not yet stable enough to be released. We expect a release within a month.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#28
post #13
post #2

Looks very promising. One thing I wonder, though, is why WYSIWYG editors still use explicit markup (bold, italic, font size) instead of allowing the definition of styles. This is a hassle if you want to write consistent documents. Even Google Documents does this; it does not have custom named styles like Word. It only has named styles for header 1..6, but usually that's not enough.

This is great input, the named styles are my absolute favourite thing about Word. One of my other peeves with almost all WYSIWYG editors is that they default to line-by-line editing, and generally avoid exposing paragraphs as a first-class construct. In both Word and HTML, treating content as paragraphs makes things more predictable, stable (in terms of layout), and easier to understand IMO.

Aloha Editor uses paragraphs as first class construct. The https://github.com/alohaeditor/Aloha-Plugin-MetaView plugin gives you a nice outline view of the used dom elements to understand the semantics. Using tags for formattings like b and i seems a good choice to me as it is the suggested formatting tag for visual bold or italic presentation in HTML5. Other formattings like (indent, etc) could be implemented as css classes, but this could cause problems when copy/paste content from on site to another as the css classes may not expose the same way. This could lead to unwanted behavior because the normal users will understand the reason.

Re: Aloha Editor - HTML5 WYSIWYG Editor

#29
post #9

There's some problems with this editor still and there's very few updates or comments in the forums, to the point where it seems like a dead, inactive project. ".mahalo()" which is the destroy method is non-functional in the current release, even though it in the documentation. Artifacts from pasting and x-browser is a bitch too. It looks promising, but it ain't ready for primetime, and don't expect get much support…

I am sorry if you feel that there is few reaction on the forum. We try to improve that. If you have a look at https://github.com/alohaeditor/Aloha-Editor/commits/dev/ you will notice that there is a lot of action going on and we are hard working on providing a better user experience with the beloved contenteditable. The probably most painful part of HTML5 spec and browser implementations. The HTML5 spec unfortunately is very unclear in most cases ("the behavior is UA-dependent" - http://dev.w3.org/html5/spec/Overview.html#user-editing-acti...). Eg. "Break block" is defined with 2 sentences, where we have more than 80 test cases and are far from complete https://github.com/alohaeditor/Aloha-Editor/blob/dev/src/tes... Though the next release (in a few weeks) should bring a better experience. PS: mahalo() should work even with the very old stable version 0.9.3. Could you point me to a implementation where it doesn't work?

Re: Aloha Editor - HTML5 WYSIWYG Editor

#30
post #17

The website is so full of hyped words I don't trust it. Advanced doesn't mean better. And I think this could be done years ago without HTML5. But it is looking nice! Inline editing is very useful!

Agree. A lot of buss words... Does that make it untrustful to you? Agree 2: It would have been possibile years ago, but would have been even more pain than it is now, where the browsers improved a lot because of the efforts Ian and his fellows at WHATWG did to write a spec (HTML5) the respects current browser implementations and tries to find a common ground for all major browsers. I think that this movement encouraged browser vendors to improve their implementations and make them more compatible.
Post reply on HN