Create - A new kind of web editing interface

Please check out mercury editor. Much nicer and active development.<p><a href="http://jejacks0n.github.com/mercury/" rel="nofollow">http://jejacks0n.github.com/mercury/</a><p>other notable and far more advanced (over create):<p>Aloha Editor <a href="http://www.aloha-editor.org/" rel="nofollow">http://www.aloha-editor.org/</a>

Inline editing is quite nice. I wonder if I am missing something about this: it seems to only offer italic/bold/underline/strike-through and no structural options?<p>Plug-and-play inline editing for various CMSs would be nice. If this had more features, I could see using it with a structured, lightweight CMS like Perch [1] to edit structured content inline with the published pages.<p>[1] <a href="http://grabaperch.com/" rel="nofollow">http://grabaperch.com/</a>

There is precisely nothing new about this idea, even though this code might be fresher.<p>It would be interesting to hear how this thing addresses some of the shortcomings of the other inline editing components out there and how this is better.

If you make this into a Wordpress plugin it would be on every install in a week.

It's obviously in its early stages, but I like the idea. Seems obvious that editing websites <i>in the website itself</i> is much more straight-forward than using some kind of backend (for small-scale CMS).

Scenario: A single backend, providing content for an ever growing set of front ends (desktop, tablet, mobile in various permutations). Content editors need to ensure things look good in all output formats.<p>Solution: Content editors get a button to preview draft content in all front ends. This opens up a tab for each front end. Front end uses the backend session to get permission to retrieve the draft content and loads up create.js during the rendering.<p>Using CORS the frontend is configured to send back any changes to the backend directly. Title width optimization can be done inline, all related pages can be updated right away.<p>All the front ends need to be able to do is identify an admin and to be able to pull the draft content and then include create.js. That is it. Booom, the front end supports inline editing. All your front ends support inline editing this way!

I was working on something similar to this (sorry, no showcase). There's a jQuery extension included for working with contentEditable text selections and formatting text with tags. I think it does a better job with overlapping tags and it merges anchor tags with same hrefs correctly. It does not work on IE &#60; 9 (I think IE9 supports the gecko contentEditable api). You might find the code useful .<p>Link to jQuery extensions: <a href="https://github.com/skid/wimp/blob/master/js/jq-extensions.js" rel="nofollow">https://github.com/skid/wimp/blob/master/js/jq-extensions.js</a>

Similar project: <a href="http://etchjs.com" rel="nofollow">http://etchjs.com</a> - An inline content editor<p>*disclosure: I released this project

To me the novelty appears to be the backend agnostic RDFa communication with the content server rather than the inline editing.<p>Would be nice if more CMS backends would support this, followed by more and more editing frontends and tools. Thereby everyone could pick the component of their choice. Even different editing frontends for different unsers on the same system would be possible.

One bug I've found: selecting more than a line and applying bold or italics is not reversible. (Win7 x32, Chrome 15.0.874.121)

many people already suggested that the idea is not novel. this implementation doesn't add what i wish we had in a modern inline content editing framework: structure.<p>wikis had it for a while now. [[newpage]] anyone? i am wondering how difficult it would be to take wikis out of their textareas.<p>the other concern is naturally security.

I would love to have this system for documentations and articles. Imagine if you let people easily improve texts, fix spelling mistakes, or translate pages, for documentation you wrote.<p>More generally, this would be awesome to use on a wiki.<p>This makes editing even more accessible.

Can you explain what this is besides setting contenteditable to true on an HTML element container? I see some other dotted lines around certain sections when you focus on them but I'm not sure how this is really powerful past just setting contenteditable.

Interesting! I'd love to see this integrated into MediaWiki once it's more feature complete.

this looks a lot like <a href="http://jejacks0n.github.com/mercury/" rel="nofollow">http://jejacks0n.github.com/mercury/</a>. Are they both from the midgard project?

WYSIWYG in HTML with JS? I doubt there is a more painful way to obtain even marginally consistent formatting...

<a href="http://vimeo.com/19366427" rel="nofollow">http://vimeo.com/19366427</a>

didn't adobe do this? i can't remember what it was called though.. but it was similar - set up in browser editable areas on existing html

how do you cancel?

I've seen Thoughtbot do this with Copycopter (<a href="https://copycopter.com/" rel="nofollow">https://copycopter.com/</a>) as well as Plone and others. It's a great way to sell user-editing features to your clientele, but I would always start with actual copy prior to enabling it as real copy is just as important as functionality for product design.<p>Yes, the marketing folks will just send you a bunch of disjointed word docs and expect you to assume that they'll fill in the blanks at a later date. Something that never happens.

Great idea, the style pop-up doesn't always close in FF. But there you have it.