The credit for writing this goes to James Hollingworth: https://github.com/jhollingworth
The spec is still not settled, but safe to use as a guideline for an implementation. If libraries align their command API implementations with the specs, it would be easy for them to port to use native commands as the browser support gets strong.
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.
It's a hit on reddit, GitHub and more for a good reason. They could have whitelisted things as well, but they chose not to.
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.
However, in a scenario like commenting or composing a message (where only limited editing options are available), storing in a format such as Markdown make sense.
He also has an interesting project called Create:
What is a table editor would essentially be a database query, with data coming from your CMS or some other system? Then instead of building a generic table by hand you could do things like Insert a table of attendees of this event, with columns displayName, company, and email.
I'll try to do some experiments with this in the summer.
Check the demo -
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 improving the documentation.
I stand by my comment about the lack of documentation though. I appreciate that it’s often difficult to get people to contribute to docs over code, but it’s pretty imperative for a project like this that there’s at least an easy integration walkthrough and a handful of examples showing common customisations.
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.
...and let the hilarity commence.
I don't consider my bolds and italics to be mere style and much less I consider them mere suggestions.
Bold and italic are typographic conventions of author _intent_ (that is: semantics) with centuries of use. I put them there in purpose, and I don't want them converted to anything else via styling. Sure, someone can style "b" as "purple text with a yellow dotted underline", but I might as well make my _actual_ intention clear.
Outside of its proper context, "semantic" is just a BS notion that got popular with designers and co because it sounds sophisticated, giving rise to inane arguments similar to how many angels fit in the head of a needle.
I'm happy when they don't use idiotic alt tags. If they manage to use good alt tags I'm really happy.
Accessible web design is seen as some freakish niche need, and is often relegated to something to do later, if ever.
Although, I think modern terminals can do bold fonts, e.g this gives you bold in bash:
echo -e "\033[1mtest\033[0m again"
From the looks of it - while just about legal, it's the worst option going. <em> etc are far more preferable and 'right'
Haven't gotten around to a github repo or fixing some pretty annoying bugs. But, there it is.
I'd tried to do this with the YUI and Dojo editors a couple years ago, but my JS-fu wasn't good enough. I'm possibly better now, and maybe wil try my hand at adding that to this editor (which looks nice for a lot of applications) but someone else with better skills could probably lay the foundation for a 'notes' system much better than me :)
I think this suggestion fully qualifies as something they don't want to do, "[to create] unmaintainable tag soups and inline styles".
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.
The code isn't officially released anywhere, but someone grabbed the source, prettied it up, and put it up here: https://github.com/benjamn/kix-standalone
Obviously you can't use it for anything without a proper license.
Oh, and I should add that the built-in parser isn't very flexible and requires lengthy configuration.
And more specifically: what are your thoughts on the Aloha editor?
What does Aloha come in at? (Web Inspector is telling me 1.6MB!)
I haven't used Aloha but my impression is that it's trying to be like all the other editors like TinyMCE or CKEditor.
wysihtml5 is lightweight, which is nice. It provides a command API so that I can wire up commands to my own toolbar and provides state management. But I don't like that some built-in commands don't offer up enough externalization, like autolinking. Or that I can't cancel an event like beforecommand. beforecommand doesn't even tell me what command is being fired. (or if it does, I couldn't find out how.)
On IE7 nothing really happens.