Html Use: SnapEditor - HTML5 WYSIWYG Editor

Download Demo

Top 5 Problems that Developers have with WYSIWYG Editors

SnapEditor solves the top 5 problems that developers have with WYSIWYG editors that we learned while interviewing over two dozen developers. All five of these things were features that we believed were important and we added six more features that we were passionate about that we believe would make you love our editor even more.

1. My Editor Is Not Really WYSIWYG

The #1 problem that developers told us about is that WYSIWYG editors are “NOT What You See Is What You Get” or N-WYSIWYG. Clients complain that viewing the content in the generated page is different than viewing it in the WYSIWYG editor. This means that developers spend time explaining and supporting a component that they did not even develop.

Solution: The solution to this problem is In-Place editing. Your users edit content right on the page in which it is displayed with the correct fonts, styles and size of the display area. Another benefit of In-Place editing is that users don’t have to load another page just to edit and yet another one after they finish editing. SnapEditor supports both In-Place editing and the more traditional Form editing.

2. My Editor Generates Bad HTML

The #2 problem is that WYSIWYG editors generate bad HTML. Pages with a WYSIWYG editor can cause pages to render incorrectly wrecking layouts and styles. A few examples of bad HTML are unnecessarily nested tags, random APPLE-STYLE-SPAN tags and weird combinations of tags especially when content is cut and pasted from another web page or word processor.

Solution: The editor needs to have an automatic HTML cleaner that ensures that the contents of the editor follow a set of consistent rules. The user won’t notice this while editing, but you’ll notice it because you always get nice clean HTML back from the editor.

3. My Editor Behaves Unpredictably

The #3 problem is that WYSIWYG editors behave unpredictably. In other words, your users expect the WYSIWYG editor to work like a word processor and it doesn’t. There are several hard technical reasons for this but it basically boils down to this: Every editor uses a “contentEditable” feature built into the browser but this feature has never been properly specified so every browser implements the features slightly differently.

Solution: The editor needs to have a cleaner (see #2 above) to make sure that the HTML is always in a consistent state. Without one there are so many unusual cases that it is hard to ensure predictable behavior. The Editor then needs to account for the differences in behavior between browsers. Third, the editor needs a Quality Assurance team that actively looks for unpredictable behavior. It is important that the team understands that unpredictable behavior is a bug and not just the user’s problem. Finally, the editor needs a full suite of unit tests that tests for these unusual behaviors and automatically runs those tests on all supported browsers before a release.

4. My Editor Needs Better Usability

The #4 problem is that WYSIWYG editors need better usability. Usability is not easy to define but we believe there are three attributes an editor needs in order to be easy to use: (1) It needs to be familiarwhich means that it works the way that user’s expect based on past experience which right now means it should work like a word processor, (2) it needs to be discoverable which means that users can figure out how to do something even if they’ve never done it before, and (3) it needs to look simple and beautiful because research has shown that an interface that looks like it is easy to use encourages engagement and usability.

Solution: A good editor needs to be developed by a team that has a Usability and Design Philosophy that includes all three attributes of good usability and adheres to them. It also needs a team with experience in user interface design as well as a designer to execute it.

5. My Editor Makes My Page Slow

The #5 problem is that WYSIWYG editors can slow down your website. This can be because the editor is too large, it is split up into too many files or it contains code that is included with the editor but you don’t use (e.g. if you don’t need tables but the table code still needs to be loaded).

Solution: We’re not all the way there on this one either but our Editor is currently no slower than any other full featured Editor right now. Everything in the editor is already modular and it’s only a few steps away from having a version that compiles only the features that you need for your editor. We are also implementing features that allow the page to be rendered before the Editor is loaded, using CSS sprites to reduce the number of connections and other strategies from the book “High Performance Web Sites”.

Top 6 Visions For The Future of Editing

In addition to the top needs we discovered during the interviews, there were several things that we felt passionate about and these make up our “No Compromise” list.

These are the features that we think you and the people who use your application will want or need and that once you start using them, there is no going back.

1. It Has to Do Both In-Place Editing and Form-Based Editing

We believe an editor designed for the future must support both In-Place editing and form-based editing. Developers should use the right tool for the job. In-Place editing is superior when WYSIWYG is important and you want to edit on the display page but a form-based editor is superior for many situations (for example for posting comments, writing a support ticket, or as part of, well, a form). If you don’t have an editor that can support both, you have to implement two solutions and this sucks for you and your clients.

2. Keyboard Shortcuts for Everything

We believe there should be a keyboard shortcut for ever action in the editor. This is especially valuable for support reps that spend 8 hours in the editor responding to tickets, or power bloggers that write their stories in the editor. These people will love that they can bullet a list, or add a row in a table, or change a paragraph to a heading without touching the mouse.

3. HTML Element and Class Whitelist

We believe that a good editor gives the developer or the designer control over what HTML elements and classes are allowed in the Editor. To do this, the Editor must have an easily readable and configurable list of element/class combinations. The beauty of this is that the Editor is easy to extend with new formatting styles that are appropriate to the web page where it will be displayed with no programming. Designers will love this.

4. Superior Image Handling

We believe that users shouldn’t have to think about how images work in an Editor, just like users don’t have to think about how images work in a word processor. Here are some problems that we know can be fixed: (1) users have to manage the images themselves using a file manager. We believe that if the user deletes the image in the Editor, the files themselves will be deleted. (2) users have to resize their images before upload. We believe the Editor should know the maximum size of the image is the width of the Editor (or whatever you tell us it should be) and automatically resize the image. (3) When users want to change resize an image, they have to upload a new version of the image in the correct size. We believe that users should be able to drag a resize handle for the image and the server would automatically render a new version of the image in the correct size.

5. Markup Compatible

We believe a good editor supports the ability to bi-directionally convert content to a markup language like Markdown and back and do it reliably. These is important for applications that must support a text only interface (e.g. if the application must work with smartphones, email or text files).

6. Plugin API that abstracts the editor

We believe that a good editor should be easy to extend without having to know the internals of how an editor works. The API should take care of all the inconsistencies and differences between browsers. Already, everything in SnapEditor is a plugin except a core API. The API currently consists of 31 functions but we have not released it yet because we believe we need to be sure these are the right 31 functions first.

Sourcing

Place the snapeditor/ directory somewhere publicly accessible by your application. For example, in a public/directory.

Assuming Snapeditor code can be reached at /snapeditor/snapeditor.js you must source it before using SnapEditor.

<script type="text/javascript" src="/snapeditor/snapeditor.js"></script>

Initialization

To initialize SnapEditor, create a new SnapEditor.InPlace or SnapEditor.Form object. Note that the object is available, but SnapEditor doesn’t initialize until the document is ready.

new SnapEditor.InPlace(<id or DOM element>, <config>)
new SnapEditor.Form(<id or DOM element>, <config>)

For more details on the possible options, refer to the Config docs.

In-Place SnapEditor

Wrap the content you wish to make editable in a div with an id.

<div id="editor">
 <p>This inner content is all editable including the p tags, but not the div tag.</p>
</div>

Add some JavaScript.

<script type="text/javascript">
 var inPlaceEditor = new SnapEditor.InPlace("editor");
</script>

Full example.

<!DOCTYPE html>
<html>
 <body>
 <div id="editor">
 <p>This is an in-place editor!</p>
 </div>
 <script type="text/javascript" src="/snapeditor/snapeditor.js"></script>
 <script type="text/javascript">
 // "editor" is the id of the div.
 var inPlaceEditor = new SnapEditor.InPlace("editor");
 </script>
 </body>
</html>

Form SnapEditor

Add an id to the textarea you want to make editable. SnapEditor will automatically hide the textarea and insert itself. The textarea will be automatically updated whenever SnapEditor loses focus. You can continue submitting your form like normal without any modifications to the form.

The size of the editor is controlled by the width and height placed on the textarea. The width and height can also be specified in the config which will override the textarea dimensions. Also, relative widths can only be specified in theconfig. For more information, check out the Configuration docs.

<textarea id="editor" name="content">
 <p>This content will be editable</p>
</textarea>