Markdown vs WYSIWYG in Symphony
- 17th December 2010
I’m a fan of using Markdown in place of WYSIWYG editors for several reasons, mainly because WYSIWYG editors are so bad. As a developer, I spend a lot of time attempting to write lightweight and elegant HTML, removing all unnecessary divs and spans, making sure all styles are in a separate CSS file and not in-line, and ensuring my sites validate to W3C standards. WYSIWYG editors guarantee none of these things.
Another reason to favour Markdown is that HTML is used to semantically describe the structure of a document, but a document’s appearance should be described separately using CSS. While Markdown only produces valid, style-free markup, WYSIWYG editors embed styles directly in HTML, reducing accessibility. For instance, your site may use different CSS rules based on the user’s device - this kind of functionality is affected by embedding styles in-line.
I recently built my first Wordpress blog for a client. I was very impressed with how simple and quick it was to set up, install a theme and customise. Then I started testing the WYSIWYG editor. Uploading and floating images, changing font sizes - doing pretty much anything unleashes a torrent of divs and in-line styles. Deleting a header and replacing it with plain text resulted in the paragraph being the same font size as the header - it’s clear the editor can become easily confused.
A lot of people argue that clients are used to Microsoft Word and something like Markdown requires too much training. Firstly, I think we have to remember (and we should try to explain to our clients) that we are not building a document which will only ever be viewed in Microsoft Word - we are building a website which will be viewed by a multitude of browsers, mobile devices, screen readers, search engine spiders etc. And secondly, I think we have to give people a little bit of credit. If they are capable of understanding the nuances of Tiny MCE, they will be able to understand and reference a Markdown guide.
Another issue with WYSIWYG editors is that it’s easy for a client to break the design - something both a designer and developer has spent hours agonising over. Pressing enter for a new paragraph, or shift and enter for a line break is generally more complicated than explaining how to create new paragraphs in Markdown. But at least when editing some content using Markdown it’s easy to see and edit the formatting characters, which is impossible using WYSIWYG (unless you ask your client to switch to plain text and delve into the HTML, or you do it for them).
So when I weigh all this up, the argument of the client being used to Word or the argument of Markdown requiring too much training doesn’t really make sense. Using a WYSIWYG editor requires us to teach our clients to always hit the “paste from word” button or paste into notepad before pasting into their editor, we have to teach them about headers, floating images, the differences between Enter and Shift+Enter and so on.
And with the WYSIWYM (what you see is what you mean) WMD Editor and the amazing Subsection Manager extensions for Symphony which create Markdown without your client having to refer to a reference guide, it’s just as easy to teach your clients about Markdown as it as about a WYSIWYG editor. And the payoff is valid, lightweight, semantic and accessible HTML, free from in-line styles, without the worry that my clients will break the design.