Maybe I am missing the point of this. It seems like they are talking about having no "backend" to manage site content. Plone has been doing this for years. Or maybe this article is about doing these things with a lighter weight framework.
Plone has always let you edit content via the web in the context of the normal web pages, not a separate admin mode.
Additionally for at least 4 years, Plone has also had a feature where you can click on various page parts (title, description, body text, image, etc) and edit inline without entering the full page edit mode. This is not enabled by default, but it is available.
The Plone 5 is scheduled to allow full control of page layout and creation of content types on the fly and in the context of the page. Take a look at
http://blip.tv/file/4310018
It starts getting interesting about 11 minutes in.
I came here to say the same thing about Drupal. Any CMS worth its salt has the same features, but I guess maybe the difference is that by leaving all the other features out, this CMS is supposed to be better. Which could be possible in theory, though I doubt it in practice.
Ah, but remember, it's the letter of the law, not the spirit, that matters.
So in this case the author has tackled that abomination that is ContentEditable and likely aged himself ten years in the process so that you can edit text on a page with no <textarea> tags in sight.
As anybody who's had the misfortune of being sucked into the ContentEditable TimeSink Vortex will tell you, that's probably not a very good idea when all you're trying to do is edit text. But from a purely technical standpoint, he has indeed done what the title describes.
I think it's also fair to say that even the spirit was met. The idea, I gathered, was to not having your typical form page where you do your creation like most typical applications have.
Their is a big difference in inline editable functionality and your typical forms for add/edit/delete functionality.
Possibly. In the current crop of browsers, it's a complete mess.
IE surprisingly has the best implementation, measured by how often you have to write specific code to insert/remove/re-insert/manually move the caret, etc. just to make a simple command work on a piece of selected text. Actually, it might not be such a surprise since they had it working back in IE5.
Webkit is quirky, but at least you can generally hack things into working.
Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them. It's completely unusable, and many trivial things simply throw non-catchable exceptions at you and refuse to work. Bugzilla is full of open bugs on the most basic things, with comments from, for instance, the Google Docs team about how they simply can't support certain features until Firefox finishes implementing ContentEditable.
> In the current crop of browsers, it's a complete mess.
I don't think this accurate.
The Facebook status update box, and other inputs, have been implemented content editable for years now. A good example of this is the field you see when composing a message, where you enter recipients' names. When you add a recipient, their name becomes a badge in the field and you can continue typing as if it were an input.
Some pretty mature JS frameworks have relied on content editable for a while too, including Ext JS.
> Firefox seems like they simply stubbed out the functions so that they could check off the box on their "HTML5 Compatibility Chart", then never implemented them.
Do a quick View Source on that facebook box, or better still download the source of any of the wysiwig dhtml editors on the market. Note that it's half a megabyte. All hacks to make ContentEditable work at all.
So yes, it's technically possible to do. That's not at issue.
The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways. The goal of the standard is to have a single easy way to flip a switch on a piece of content and have it editable in a way that you can quickly hook up your "bold" button, etc.
It's a long way away from that today. Try implementing a simple WYSIWYG editor for yourself, then note the large bald patches on your head and corresponding clumps of hair in your white-knuckled fists. That's not something that you get with other areas of the HTML5 spec.
Writing your own wrapper on contenteditable is like rewriting jQuery. Yes it's a messy complicated problem. That's why you don't do it yourself.
Something like TinyMCE is incredibly configurable and has had years to work around the browser quirks in contenteditable. Use it wherever possible.
On a side note I recently exchanged some emails between the lead dev on TinyMCE and the person working on the Webkit implementation of contenteditable. I had very little luck persuading them to communicate. The fault was mainly on the webkit end of things. I find it astonishing there isn't better communication between people at this level. The number of people using TinyMCE via Wordpress must be in the millions. You'd think people working on Webkit would be seeking them out for advice on implementation bugs.
Not only is it technically possible, but it's being used reliably in production environments.
> ... have it editable in a way that you can quickly hook up your "bold" button, etc.
Today in any current browser you can do execCommand("bold") to embolden text.
> The problem is that it's implemented in five completely separate ways by five different browser vendors. Many things are implemented in mutually exclusive ways.
Implementing a unified XHR wrapper could also make someone aggravated, as there are different -- sometimes completely incompatible -- implementations across browsers. Having varying implementations comes with the territory and is not an indication of brokenness.
You keep making these blanket statements without providing any examples. Can you give one example of actual code that needs major workaround? Your off-the-cuff example of a bold button makes me wonder if it wasn't five years ago when you last tried to make this happen.
If anyone is interested in a more disciplined understanding of the various levels of support across browsers, here's Quirksmode's take on it: http://www.quirksmode.org/dom/execCommand.html
Today in any current browser you can do execCommand("bold") to embolden text.
Indeed. And it will work, provided you haven't used Backspace to collapse your selection to the start of a DIV in IE. And you haven't selected your text by SHIFT+Left Arrow such that it oversteps the beginning of an editable paragraph and enters the no-mans-land between it and the non-editable div before it in Firefox. And you haven't previously issued an "insertorderedlist", causing the known issue in IE. And that you didn't issue your contentEditable=true as the result of the mouse click that placed the caret inside the text of a H1 tag.
And dozens of other tiny things that continually jump out to bite you that need to be worked around in every single browser just to get it to work.
So yes, I'll grant you "technically possible", but not anything beyond that.
I ask, because I tried to once. After a bunch of unsuccessful shoehorning, and marveling at how they could write an entire megabyte of javascript and still not end up with a working editor, I gave up and rolled my own.
It actually made diving into ContentEditable seem like the less painful choice.
Benjamin here from the Aloha Editor Team. You are completely right that Aloha Editor is pretty big right now; as Bergie as mentioned this is due it's ExtJS dependency. The Aloha Team has now partnered with the jQuery UI team and development is underway to shed this dependency and use the much lighter jQuery UI framework as the default.
You can follow the status here http://aloha-editor.org/wiki/Roadmap and we're totally open to as much feedback you'd like to throw at us :-) We're here to help!
I've been wrestling with the idea of using contentEditable in my project for a while now. On one hand it's a great way to let users edit text, very friendly. On the other hand, you'll need a javascript toolbar, and you're limited to things that are expressible as HTML.
Why don't all Content Management Systems work this way?
The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend.
I've found that new WordPress users are confused as to why, for example, the text they type in the post editor is set in a serif typeface when their site is displayed in sans-serif, or when their H2 tags are larger in the post editor than on the site itself. And those are only tiny examples -- I'd guess that a large proportion of new user (dis)orientation is related to the enforced disconnected backend that the majority of content management systems adopt.
I think WordPress et al could hugely benefit from a pure edit-in-place model, with overlays or sidebars for any non-visible configuration like permalinks, draft posts, and email settings. WordPress 3.1 moved the admin bar onto the front page; perhaps this is a sign that more of the backend is to follow?
In our first prototypes we were experimenting with inline editing, but we actually decided against it.
The really good thing with allowing editing right on the site is that it matches non-technical end-users conceptual model of a website far, far better than some abstract admin backend for their content.
This is a big deal, since for many users even something as seemingly simple as Wordpress can be really hard to explain. They just don't intuitively understand that there's a database somewhere with content that are then sucked into their website and displayed. And when they want to edit something on their site, they don't want to go somewhere else to look for it.
The bad thing, in my opinion, with actually doing inline editing, is that the end users conceptual model is actually wrong. There really is a difference between content and design. The same content can often be displayed in many different places and used in different ways.
Sometimes you have an article with a long text and big photo, but choose to only show the first paragraph of the text as an excerpt on the front page together with a thumbnail version of the photo. Or you truncate the title to a short version to show a teaser for the article in a small box in the sidebar, etc, etc.
If the user clicks on the excerpt of his long text to edit it, inline editing starts getting problematic. Do you allow him to edit only the first paragraph inline, leaving the user unaware that he might make the next paragraph in the article sound really weird if he change it? Or do you expand it to the full text with the risk that the design will get completely mangled?
Some of these problems are solvable if you limit how the designer can use the content and what HTML/CSS he can write (CSS can really mess with inline editing as well - just think about overflow: hidden or white-space:nowrap).
That's why we went for a small miniform triggered by clicking directly on the content you want to edit, but with a link to the full form for that content. We want to gently guide the user towards the right mental model of how their website works, without forcing them to go search for the right content in a backend interface whenever they want to edit something.
>The edit-in-place model as demonstrated in this post makes so much sense. It seems crazy to have a CMS with a separate backend when the backend can be the frontend.
Absolutely. In my experience "normal" users are much less confused - and more likely to actually manage their content - when they can edit their content in context instead of in an entirely separate interface.
Concrete5 CMS is pretty good at this - though the code behind the scenes is a bit wonky. This UI looks quite nice as well, but again behind the scenes... And I've yet to see a Rails CMS implement this at all (though I'm keeping my fingers crossed - please HN prove me wrong).
This allows you to still communicate with a separate backend, just implement Backbone.sync in the way you need. There is even a guy implementing this system for Jekyll (a static HTML blog generation tool)
Perhaps that's why WordPress doesn't do it yet. To offload CMS functionality onto theme designers (and to make it a requirement to be able to use WP) might prove disastrous; the editing experience could become inconsistent between themes.
I would guess it is in part because a lot of them carry around far too much baggage that adding this in afterwards is too much work.
I am having a shot at it with django. Rather early yet, but doing something like this is the goal. It only really exists on svn right now http://codefisher.org/svn/djangopress/
WordPress 3.0's default theme applied the same CSS to the backend post editor as well as was used on the the front page. Well, that was the idea, anyway. It sounds like it didn't work out so well.
That's interesting -- I didn't know that. I've just logged into one of my sites, and the editor is using the 'content.css' stylesheet from tinymce, rather than inheriting styles from the homepage.
1. Not really, but you can download and run it yourself. Online demo will come at some point later
2. We're passing JSON-LD (http://json-ld.org/) over the standard Backbone.sync API (http://documentcloud.github.com/backbone/#Sync). But for other systems that can be replaced with a different JS implementation to the fit the API conventions of the back-end you talk with. Just override Backbone.sync
It's nice, as long as no one is trying to use your site from an ipad or other tablet or phone that doesn't support contenteditable well (i.e., all of them).
Others are starting to find workarounds by using a hidden textfield that captures input. I haven't tested them on a tablet or mobile phone yet, though. See the Ace editor and Codemirror 2: http://codemirror.net/2/internals.htmlhttp://ace.ajax.org/ (yes I know those are code editors, not wywsiwyg rich text editors, but I'm just pointing to solutions that might possibly work better on mobile platforms)
Another, perhaps kludgier workaround is to use a floating css keyboard for mobile users to enter text.
Lack of proper contentEditable support on typical mobile devices is indeed an issue. iOS somewhat supports it, for example you can make formatting changes but don't get a keyboard. There are some ways to go around this:
* Wait for Apple to fix this issue (there is a bug open)
* Implement a form-based workaround or do a on-screen keyboard in JavaScript
* Do something completely different. We've had quite good experiences in publishing from mobile devices via email
We've built our own inline editor for Orbs, a website builder project which we posted to Hacker News last year. You can see it at http://www.orbs.com/. Basically, you just click on the content and the editor starts working in place. This version actually uses an iFrame but copies the CSS styles in so it works exactly like inline editing.
When we asked for feedback, there was a comment that was particularly interesting where the user said he'd pay for something like that if he could edit his regular website with it. Basically a CMS.
It was such a good idea that we built it and it's available at http://www.designhamster.com/. Basically, you just add a class="EDIT" attribute to any div you want to make editable. We plan on making a real post to Hacker News about it later. This version is actually making the DIV editable instead of an iFrame.
There is a live demo on that page where you can click on a box with some text in it and try it out on the DH home page; however, to get a real feel for it, I'd suggest using the free signup so you get an idea how it works in a page.
Note: DesignHamster is live and accepting customers but we aren't going to promote until we improve the interface. This will be done in 2 weeks. It is completely usable now though for projects.
So, you are using Aloha editor. It's kind of cool but still buggy (I'm sure this will be cleaned up) and I understand it's quite heavy. I think we did ours in 66KB + mootools.
If you are wondering, making an editor from scratch is HUGE work. To get bold, italic, headings, bullets, and everything else that is built into the browser's execCommand list for working with contenteditable gets you a lot of cool stuff for almost zero pain. It's fun, enjoyable and fast to build. This gives you the false impression that the rest will be just as easy. Unfortunately, not even close.
Every browser is different is just the beginning. There are bugs galore in each browser. Some of the worst offenders are from our favorite browsers like Chrome and Safari too. Try and backspace from a paragraph into a heading and you'll get these weird inline SPAN that fake the formatting of the H1/P tag without actually being one. In many instances, IE has the sanest behavior. To fix this, we override the handling of delete, backspace and enter depending on the browser. If the browser handles it correctly, we don't touch it. But if it doesn't, we modify the DOM directly.
In other areas like selecting an image, IE uses a completely different selection object type for images than text. This has to be handled specially too.
Many commands not built in require manipulation of the DOM. But unfortunately that kills your UNDO. So if you want to keep undo working, you have to build your own UNDO stack.
Then there are just plain weird bugs. I think there was one where if you have an image in a P tag with nothing else, in one of the browsers, your cursor can't move passed it. So to fix it, we had to insert an invisible space.
For us, the editor is one of the most valuable assets of the company which is why we have spend, probably over a man-year working and improving our editor. We are getting better at it but it's still not perfect. We want the editor to be a prime differentiator of our product so we are willing to put in the work; however, be warned that working directly on creating an editor is a lot of work.
Plone has always let you edit content via the web in the context of the normal web pages, not a separate admin mode.
Additionally for at least 4 years, Plone has also had a feature where you can click on various page parts (title, description, body text, image, etc) and edit inline without entering the full page edit mode. This is not enabled by default, but it is available.
The Plone 5 is scheduled to allow full control of page layout and creation of content types on the fly and in the context of the page. Take a look at
It starts getting interesting about 11 minutes in.