Piotrek Koszuliński Reinmar

Strictly Frameworks

Mobiledoc - https://github.com/bustle/mobiledoc-kit - framework to build editors with a standardized JSON structure
Substance - http://substance.io - library for building editors and publishing systems
ShareDB - https://github.com/share/sharedb - framework to sync any JSON document using operational transforms, add real-time collaborative editing to anything else

Abstracted Editors

These use separate document structures instead of HTML, some are more modular libraries than full editors

ProseMirror - http://prosemirror.net/ - supports collaborative editing, offers similar options to Mobiledoc for data structure

Process

We code the features using the t() functions in which we define the English value of a string (and, optionally, a context). E.g. t( 'Bold' ) or t( 'Button [context: clothing]' ) (the [context: clothing] will be automatically removed upon build on, in the dev mode, on runtime). Each context must be defined in lang/contexts.json of a package which uses it or in the ckeditor5-core/lang/contexts.json (for common strings).
From time to time, we run a tool which scans code for all t() usages, extract strings from it, builds a contexts map (based on all lang/contexts.json files) and checks whether all used strings have defined contexts. Then builds a PO file with English strings and contexts and upload it to Transifex.
Then we run a tool which downloads all PO files for all defined language and put them back in lang/ directories.
When building an editor, a specific bundler read PO files and create translation map(s) for chosen language(s) based on them and bundles those as d

Reasons why it doesn't make sense to make jQuery CKEditor's dependency

CKEditor would use very limited part of jQuery - only basic DOM methods, some tools maybe.
CKEditor needs very specific DOM methods. The vast majority of features implemented in CKEDITOR.dom.* are not available in jQuery. Huge range API, walker, iterator, editing-specific DOM traversal methods, etc. (really - >75% of dom.*) - all of that would have to be implemented.
I don't know how jQuery's API can be extended, but I guess that CKEditor's extensions would look ridiculous. Overall effect could not be good.
CKEditor deals with extreme browser bugs (contenteditable FTW!) and very uncommon DOM operations and algorithms, so even existing jQuery's features may not be suitable in some cases. Currently we have full control over methods' implementation, so we may introduce necessary tweaks.
CKEditor rarely works on collections of elements - jQuery API's biggest feature would not be consumed. Moreover - it would be a perfo

TL;DR I'm a CKEditor core dev, I watched http://vimeo.com/76219173 in which CKEditor was mentioned, I'm sad now.

Disclaimer: I am a CKEditor core developer since January 2012, so I've been working nearly exclusively with contenteditable for almost two years. That made me an expert in some of fields that WYSIWYG editor deals with and gave me a decent knowledge about the rest. Although, my opinion may be biased.

I watched the video from "contenteditable: Roll for sanity" presentation by Garann Means with great interest. The contenteditable feature is a base for all WYSIWYG editors (except those with completely custom rendering system like Google Docs), but is not popular and most web developers have no idea about such thing (what on the other hand does not surprise me). What's more, those who stumble upon it quite often fall into the standard trap:

Hey, we just met and this is crazy, but we've got few hours so let's create a new WYSIWYG editor maybe!

This approach to web devel

	(master 041eec8) p@m /www/ckeditor5/ckeditor5-core> npm set progress=false
	(master 041eec8) p@m /www/ckeditor5/ckeditor5-core> rm -rf ~/.npm && rm -rf node_modules/
	(master 041eec8) p@m /www/ckeditor5/ckeditor5-core> time npm install
	npm WARN deprecated [email protected]: lodash@<2.0.0 is no longer maintained. Upgrade to lodash@^3.0.0
	npm WARN prefer global [email protected] should be installed with -g

	> [email protected] postinstall /www/ckeditor5/ckeditor5-core/node_modules/guppy-pre-commit
	> guppy pre-commit

	guppy: Installed git-hook: /www/ckeditor5/ckeditor5-core/.git/hooks/pre-commit

	12006 silly mapToRegistry uri https://registry.npmjs.org/regjsparser
	12007 verbose request uri https://registry.npmjs.org/regenerate
	12008 verbose request no auth needed
	12009 info attempt registry request try #1 at 11:18:29 PM
	12010 verbose request using bearer token for auth
	12011 verbose etag "5ON53K48516Y2UVNMVYERXQLI"
	12012 http request GET https://registry.npmjs.org/regenerate
	12013 verbose request uri https://registry.npmjs.org/regjsparser
	12014 verbose request no auth needed
	12015 info attempt registry request try #1 at 11:18:29 PM

	# HEAD detached at 4.4.4
	# Changes not staged for commit:
	# (use "git add/rm <file>..." to update what will be committed)
	# (use "git checkout -- <file>..." to discard changes in working directory)
	#
	# deleted: plugins/a11yhelp/dialogs/a11yhelp.js
	# deleted: plugins/a11yhelp/dialogs/lang/_translationstatus.txt
	# deleted: plugins/a11yhelp/dialogs/lang/ar.js
	# deleted: plugins/a11yhelp/dialogs/lang/bg.js
	# deleted: plugins/a11yhelp/dialogs/lang/ca.js

	CKTESTER.editor = { config : { autoParagraph : false } };

	CKTESTER.test(
	{
	test_a : function()
	{
	var editor = this.editor,
	editable = editor.editable();

	editable.setHtml( 'abcdef' );

	// I've just found shit like this:

	var sth =
	option.type == 't1'
	? v1
	: option.type == 't2'
	? v2
	: option.type == 't3'
	? v3
	: null;