Looking at the examples, I don't understand how this is "a better approach" to editing, because the HTML it outputs does not follow best practices. The HTML it outputs should look like a competent human had authored it, but currently it uses line-break hacks for paragraphs instead of semantic paragraph elements (two <br> elements aren't really a paragraph, it just looks like it), adds underline elements with Ctrl+U (underlines should be reserved for links and defined in stylesheets anyway) etc.
WYSIHTML5: A better approach to rich text editing
31–40 of 82 posts
Re: WYSIHTML5: A better approach to rich text editing
#32Looking at the examples, I don't understand how this is "a better approach" to editing, because the HTML it outputs does not follow best practices. The HTML it outputs should look like a competent human had authored it, but currently it uses line-break hacks for paragraphs instead of semantic paragraph elements (two <br> elements aren't really a paragraph, it just looks like it), adds underline elements with Ctrl+U (these should be reserved for links and defined in stylesheets anyway) etc.
Re: WYSIHTML5: A better approach to rich text editing
#33Wouldn't it be more desirable to have these WYSIWYG editors serialize to a non-HTML markup (like textile or markdown) to reduce the hassle of user-input sanitization on the back-end? (e.g. stripping script and iframe tags). What's best-practice these days for storing and displaying rich-edit user input?
I doubt Markdown, BBCode or anything similar is a good idea here. That's just introducing extra complexity - and what for? The point of markdown is that its simple for humans to read and write directly, which isn't applicable here.
The downside to markdown should be obvious:
* more code, both server and client-side (to implement the to-and-from conversion)
* more bugs (due to more code and the complexity of escaping valid input that happens to be markup in one or the other)
* less features (if the editor supports some html that doesn't map 1-to-1 to markdown, you're in trouble)
* less future-proof/platform independent (html isn't going anywhere, but that markdown variant you're using with the custom extensions you needed might be subtly different in whatever language/platform/toolkit you'd prefer in 5 years).
Html is by far the better choice. If there's an improvement to be had here, it's in using the (compatible) XHTML5 serialization to ease parsing. And it's quite likely already using that, since that's what browsers' rich-text-editing generally produces.
Re: WYSIHTML5: A better approach to rich text editing
#34How is it doing the speech input for Chrome? Is this an offline API provided by Chrome or backed by a Google web api?
Re: WYSIHTML5: A better approach to rich text editing
#35Earlier quoted context omitted.
Aloha is more than a meg of JS as it stands and the documentation is pitiful.
I'm a contributor to Aloha and recently project underwent a huge re-write to cut down the cruft. Next release, will use a light weight UI based on jQuery and also switching to a newer command API based on W3C's editing API will also make things more faster (and easier). Main issue with the documentation was the rapid changes to the API in the past. Since the API is getting stable there will be more concern on improvi…
That sounds very promising. Do you have a time frame for this release?
Re: WYSIHTML5: A better approach to rich text editing
#36Feature request - ability to add 'notes' to a document. I'd imagine these as toggleable divs that would be able to be inserted anywhere in the doc, then made visible or not by toggling a class. When 'on' the visible portion would just be a small box/space/marker that, when clicked, opened up a larger div with the full note. I'd tried to do this with the YUI and Dojo editors a couple years ago, but my JS-fu wasn't goo…
> Feature request - ability to add 'notes' to a document. I'd imagine these as toggleable divs that would be able to be inserted anywhere in the doc, then made visible or not by toggling a class. When 'on' the visible portion would just be a small box/space/marker that, when clicked, opened up a larger div with the full note. I think this suggestion fully qualifies as something they don't want to do, "[to create] unm…
Who said inline styles? A class and an ID on a span tag inside a larger block would be all that's required. The clicking stuff would be applied outside of the document editing area.
This is the sort of reaction that makes me hesitant to even attempt to fork/patch it, because if this sort of thing wouldn't be accepted back in to the main trunk, I'm stuck maintaining a separate branch.
Re: WYSIHTML5: A better approach to rich text editing
#37Wouldn't it be more desirable to have these WYSIWYG editors serialize to a non-HTML markup (like textile or markdown) to reduce the hassle of user-input sanitization on the back-end? (e.g. stripping script and iframe tags). What's best-practice these days for storing and displaying rich-edit user input?
If you would be happy with markdown, you'll be happy with a whitelist-based HTML sanitizer. HTML santization is only a hassle if you take the blacklist approach in an attempt to allow lots more than what markdown can do.
I've used antisamy, but there are many others and I don't know which is best. But I would call the whitelist approach in general, best practice.
Re: WYSIHTML5: A better approach to rich text editing
#38This is a fantastic rich text editor, easily one of the best I've seen. If I remember correctly, 37signals uses it in the note writing feature of the new Basecamp.
Correct.
Re: WYSIHTML5: A better approach to rich text editing
#39Earlier quoted context omitted.
I'm a contributor to Aloha and recently project underwent a huge re-write to cut down the cruft. Next release, will use a light weight UI based on jQuery and also switching to a newer command API based on W3C's editing API will also make things more faster (and easier). Main issue with the documentation was the rapid changes to the API in the past. Since the API is getting stable there will be more concern on improvi…
That sounds very promising. Do you have a time frame for this release?
I among others will work on the dev-jqueryui branch in June. I hope we will manage to stabilize it and merge it to dev in this time.
It should be noted that we plan to make the ui an optional part of Aloha (with default being a jqueryui implementation) to make it easier to integrate into existing systems. The heavy extjs dependency is part of why Aloha is so huge.
I also plan to look into using google closure compiler in ADVANCED_OPTIMIZATION mode to shrink the size to the absolute minimum.
Re: WYSIHTML5: A better approach to rich text editing
#40IE in browser support: IE8+ yay ;-)
Out of curiosity is it working in IE8 for you? Doesn't appear to fully work for me using IE8 on XP. The editor buttons and most of the page don't appear.