
Build a CMS, no forms allowed - bergie
http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/
======
leejoramo
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.

~~~
nowarninglabel
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.

------
Udo
While it's a very cool app (also, kudos on reducing the huge framework stack),
I still believe an in-page text editor _is_ actually a form.

~~~
jasonkester
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.

~~~
masklinn
Hasn't the WhatWG done a lot of work trying to formalize the workings of
ContentEditable in order to include it in the HTML5 spec?

~~~
jasonkester
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.

~~~
jessedhillon
> 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.

Which functions don't work?

~~~
jasonkester
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.

~~~
jessedhillon
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>

~~~
jasonkester
_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.

------
bergie
The relevant GitHub repositories are:

<https://github.com/bergie/midgardmvc_ui_create> \- the reference UI
implementation for Midgard Create

<https://github.com/bergie/VIE> \- JavaScript library used for making RDFa-
annotated content editable

<https://github.com/alohaeditor/Aloha-Editor> \- usable HTML5 contentEditable
implementation

<https://github.com/midgardproject/midgardmvc_core> \- the PHP framework used
with the UI reference implementation

If you want to implement this UI, or something similar to your web system,
just let me know. I'm usually on Freenode #midgard and #iks channels.

------
modernerd
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?

~~~
timclark
I prefer that the content rendering system should be completely seperate from
the content editing system - very few systems do that though.

In my experience the rendering system and editing system probably have very
different performance and scalability requirements.

I agree that having the edited content looking visually different from the
rendered content is usually a bad thing.

~~~
bergie
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)

~~~
balupton
That guy has a name Bergie! Hehehe.

It's me btw :)

------
edambauskas
1\. Is there a demo of the CMS somewhere?

2.Is the API for the JSON/REST backend documented anywhere?

It is awesome to see someone implement this architecture.

I have been working on a similar concept for quite a while, but didn't have
time to build anything more that prototypes and proof-of-concepts.

~~~
bergie
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

If you're working on something similar, then our JS libs will probably be
handy: <https://github.com/bergie/VIE>

------
edtechdev
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.html>
<http://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.

~~~
bergie
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

~~~
wladimir
Interesting... Does Google Docs address this problem on iOS?

I believe I read that Google Docs does not use contentEditable, but emulates
it by catching keyboard events directly.

~~~
alanh
Wait, Google Docs supports editing on iOS at all?

------
thesunny
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.

