Top myths about using the WYSIWYG editor
If not entangled in a love-hate relationship, WYSIWYG (standing for “what you see is what you get”) editors are usually taken for granted by the online community. Most users think sites and CMSs naturally come with such tools, which couldn’t be further from the truth. Unless a site uses a CMS like Drupal 8 that includes CKEditor by default, developers and site owners have to manually implement them.
Newcomers to the WYSIWYG scene have to unfortunately deal with a variety of misconceptions surrounding online rich text editors. The following article will cover some of those myths and try to demystify them because in the right hands a powerful WYSIWYG HTML editor can be a great asset to your site.
So let’s begin…
They are like Word
This one is at the top of every WYSIWYG editor’s list of myths. Though they can in theory perform like desktop word processors with a bit of tweaking, content pasted to an HTML editor will often look slightly different than in Microsoft Word for a couple of reasons.
First, unlike desktop word processing apps designed primarily for printing static layouts, online editors generate HTML (or HyperText Markup Language) designed for dynamic web pages. That reason alone makes them diametrically different.
Secondly, editors like CKEditor don’t generate formatted content; they help you generate semantic content. Formatting and semantics are two different things. Semantic content is designed with future technologies in mind, like mobiles, screen readers for accessibility, and the plethora of current and future bots crawling the net. Formatted content, on the other hand, is lifeless.
Having said that, Word content doesn’t include any of the semantic elements of the Web. It needs to be converted by a WYSIWYG editor, and that changes the look and feel - it’s unavoidable.
They can save in different formats
As stated in the above myth, online WYSIWYG editors aren’t desktop applications so they can’t convert or save to any specific file format, like .docx or PDF. There are ways to convert saved HTML source code but you would need to install special converters on the server and it wouldn’t be the editor’s job.
They are similar to Google Docs
Myth! WYSIWYG editors are designed to modify the content of your pages. Google Docs, on the other hand, acts almost like an iframe within your page and is designed for print, not for the web. Although CKEditor can be customized to include some Google Docs features, we’re still talking about different technologies.
They slow down your site
WYSIWYG editors are small compared to the tasks they are meant to perform. We’re talking about apps a couple of hundred kilobytes in size that are expected to behave like heavyweight desktop word processors.
Moreover, they are expected to run smoothly on a variety of browsers, which themselves have different versions and vary between operating systems. And let’s not forget the various platforms: PHP, ASP.NET, Classic ASP, Java, ColdFusion, etc.
They are website builders
WYSIWYG editors are neither graphical web design tools nor website builders. They have nothing to do with Dreamweaver or CoffeeCup. Online text editors simply let you create rich, semantic content online on pre-existing pages.
They generate bad code
This one originates from the myth that WYSIWYG editors are similar to website builders, which sometimes create redundant code.
Online rich text editors like CKEditor generate a large portion of the HTML content online. CKEditor’s core developers are often involved in important W3C discussions, so it’s downright misinformed to even insinuate that CKEditor generates bad code. If anything, people complain that CKEditor is too strict about generating valid HTML, not the other way around.
They’re not secure
If I may again compare WYSIWYG editors to word processors, even the famous Office Word gets patches to fix the occasional issue, so no system is entirely secure.
All things considered, WYSIWYG editors are quite secure if properly maintained. They are designed to always be online, which makes them more exposed to the “elements”, and yet we rarely hear about exploits. CKEditor is Open Source so its inner workings are always scrutinized and improved by people the world over.
They improve your site’s security
Big clients sometimes surprise us with this myth. The CKSource team was asked on a few occasions to develop custom filtering tools that would strip unwanted elements, despite CKEditor already having such a feature in the form of an Advanced Content Filter (ACF).
Though ACF can filter code, it does so purely for aesthetic and usability reasons. It gives web developers control over the uniformity of content in websites. It won’t prevent even semi-competent hackers from bypassing this filtering tool because WYSIWYG editors can be turned off on the client side via the browser’s developer console. All desired filtering mechanisms have to be implemented on the server to be effective.
They have direct access to your server
This myth is directly related to the one above. The security misconception stems from the assumption that CKEditor somehow is attached to the host server. It’s not, and it doesn’t interact with it in any direct way. All WYSIWYG editors do is send or receive HTML, which is either grabbed or sent by the server.
Yes, CKEditor can show dynamic content pulled from a server; yes, it can filter code; yes, it can modify content in your database, but all this is done indirectly. You need to have additional code overseeing the connection between the editor and the server because such behavior isn’t inherent to the editor.
They’re not accessible
Though this might be true for some editors, there’s no special reason why WYSIWYG editors can’t be accessible since they use browsers to function. CKEditor is quite possibly the most accessible rich text editor online, meeting the requirements of Web Content Accessibility Guidelines (WCAG) and Section 508. It has also been adapted to pass a variety of criteria on IBM’s Web Accessibility Checklist.
It should be noted that since online WYSIWYG editors need browsers to function, they sometimes inherit each browser’s accessibility flaws. There’s not much that can be done here.
They’re not truly WYSIWYG
WYSIWYG editors with editing forms are limited by the surrounding frame, but even framed editors have features that enable them to inherit the website’s styles so the content will look much like the final version.
Additionally, since the advent of inline editing (or as Drupal calls it, “in-place editing”), editors are now able to edit live pages without requiring a frame. You can see CKEditor’s inline feature in action here.
They’re difficult to implement
Another myth. If the guides are clear and the editor isn’t dependent on third-party libraries like jQuery that need to be separately configured, installing a WYSIWYG editor should be a breeze. In CKEditor’s case, implementing the editor is done in 4 steps.
- Uploading the editor to your site’s server
- Defining on which page you want CKEditor enabled
- Telling your page where to load CKEditor
- Defining the saving mechanism
The only problem might be connecting your site’s saving mechanism to the editor, but if your site already saves data somewhere, figuring this out shouldn’t be a problem even for casual developers.
Now get yourself a WYSIWYG editor!
So there you have it. WYSIWYG editors are unfortunately the victim of the Internet’s complexity and unfair comparisons to other technologies. It’s a shame, too, since they can increase work productivity and make your site more appealing and rich with information. If you were ever on the fence about adding a rich text editor to your site, I hope this piece helped demystify some misconceptions.
