Mercury Editor: WYSIWYG inline editing for Rails via HTML5 contentEditable

Editing without iframes: how HTML5 contentEditable keeps CSS on the page

Traditional WYSIWYG editors such as TinyMCE and CKEditor place an iframe around the editable area. Styles defined on the outer page stop applying inside that iframe, so a heading font or custom spacing rule becomes invisible to the person writing content, because the iframe creates a separate document context.

What changes with Mercury's approach is the document context itself. Block elements on the actual page carry the contentEditable attribute, so editing and rendering share one DOM tree. The CSS that styles the published version of a paragraph also styles it in edit mode.

The toolbar appears once per page, not once per region. Mercury makes no provision for per-region toolbars: the same controls cover all editable areas, and the README describes this as the intended design.

Three generators from mercury-rails: configuration, image upload and authentication

Mercury ships as a Rails gem under the name mercury-rails. Adding it to a Gemfile is the first step:

gem 'mercury-rails'

After bundling, the main generator sets up the configuration:

rails generate mercury:install

/app/assets/javascripts/mercury.js is where the configuration and the Sprockets manifest for Mercury's assets both land after the generator runs.

A second generator handles image upload scaffolding:

rails generate mercury:install:images

The --orm=mongoid flag steers the image generator toward Mongoid; without it, the output targets ActiveRecord and a migration is still needed. The Gemfile gains paperclip after the image generator runs, with mongoid_paperclip added when --orm=mongoid was used.

Authentication gets its own generator:

rails generate mercury:install:authentication

What the authentication generator creates is a hook point in MercuryController with no logic yet. Adding the actual checks is left to the developer, because the necessary logic differs too much across applications to generalize.

For non-Rails environments, the README points to a zip archive last packaged as mercury-v0.9.0.zip. The gh-pages branch is mentioned as a resource for integrating the Mercury bundle into a static site.

Full HTML, Markdown, Snippet, Image and Simple: the five region types and what the README documents

Full HTML, Markdown, Image and Simple lack documentation beyond their names in the 'Custom Regions' entry of the README. Only Snippet comes with a behavioral description: the README calls this content 'predefined and reusable bits of markup/code', placed by drag and drop.

Having five distinct types matters because the editing surface a Mercury page presents depends entirely on which type each area carries. A page that needs different constraints in different areas maps each area to a different region type. How the Full HTML, Markdown, Image and Simple types enforce or relax constraints is not documented in the README beyond their names.

Image drag-and-drop, YouTube and Vimeo embeds, and the table editor

A desktop file dragged into a Mercury region gets picked up, sent to the back-end upload endpoint created by the mercury:install:images generator, and placed in the region automatically.

For video, the media tools work with YouTube and Vimeo. Those are the two services named in the README's Features list; nothing there covers other video platforms or self-hosted files. A project that needs video from a different source has to handle that integration separately.

For tables, the README uses the phrase 'column and rows spans' to describe what the table editor handles. That phrasing covers both multi-column and multi-row spans in a single cell, going further than basic table editing, which stops at adding rows and columns to a fixed grid.

The link tool distinguishes between external URLs and in-page anchors for table-of-contents entries and bookmarks. A preview toggle is available during editing, showing the rendered output without leaving the editor context. Mercury's I18n system is described in the README as 'low profile', built in as a default rather than requiring a separate gem.

Browser version floors: Internet Explorer 10, Chrome 10, Firefox 4, Safari 5 and Opera 11.64

Mercury sets a floor rather than a ceiling for browser support. The floor given in the README is Internet Explorer 10, Chrome 10, Firefox 4, Safari 5, Opera 11.64 and Mobile Safari on iOS 5.

Mercury's browser policy starts from the W3C content editing specification rather than from installed-base data. A browser that implements the spec is supported; one that diverges from it is not. No plans to add support for non-conforming implementations are mentioned in the README.

For the listed browsers, there is no compatibility matrix beyond the version floors. A project evaluating Mercury needs to test against its actual audience's browser distribution, because the README documents no results for specific versions within the supported ranges.

TinyMCE, CKEditor and the seven alternatives the README names

The README names seven editors for readers who decide Mercury does not fit: Aloha Editor, jHtmlArea, MarkItUp, TinyMCE, CKEditor, NicEdit and Raptor Editor. TinyMCE and CKEditor are the primary reference points, because the README opens by describing Mercury as 'much like TinyMCE or CKEditor, but with a different usage paradigm.'

That paradigm difference is the one already described: TinyMCE and CKEditor use iframes, while Mercury uses contentEditable. For an application where CSS continuity between the published page and the editing surface makes no practical difference, those iframe-based editors are established options with active documentation and community support.

The list itself is unusual. A README that presents alternatives usually does so without admitting they might be a better fit; Mercury's does not, naming seven editors and noting that browser coverage or feature gaps may point toward one of them instead.

Rails 3.2, CoffeeScript and what the repository layout and topic tags reveal

On the client, Mercury is CoffeeScript and jQuery; on the server, it expects Rails 3.2. Adopting the gem means taking on those dependencies, along with paperclip from the image upload generator and mongoid_paperclip when the Mongoid variant is selected. The README documents no compatibility with Rails versions after 3.2.

A reader who checks the repository's topic tags and the Developer Note together finds a detail a quick scan would miss: the repository carries the topic tag deprecated-repo, the Developer Note states the master branch is 'no longer maintained by me', and the last push to that branch was dated 2026-10-06. Both signals point to the mercury2 branch as the project's destination while the master branch continues to carry a recent timestamp.

The repository layout covers the expected files: .gitignore, .travis.yml, Gemfile, Rakefile, a mercury-rails.gemspec, an app/ directory and a spec/ directory. Anyone tracing the build setup can start from the gemspec and Rakefile. Before deciding which branch to evaluate, confirm the mercury2 branch's Rails version target and recent commit history.

Editorial conclusion

Mercury Editor solves one problem: giving a Rails application an inline WYSIWYG editing mode where CSS continues to apply to editable regions. For that task, the gem and its three generators give a working starting point. Do not adopt it for a new project. The repository carries a deprecated-repo tag, the Developer Note says the master branch is no longer maintained, and the gem was written for Rails 3.2 with CoffeeScript and jQuery. Confirm your application runs Rails 3.2 before spending time evaluating it, because the README documents no compatibility with later versions. Read the custom licence file before any redistribution.

Frequently asked questions

Official sources

1. Issues
2. jejacks0n/mercury on GitHub
3. Project website
4. README