A few days ago I talked about the Email and P Myth, but didn’t explain why it’s so frustrating for editor developers that people keep wanting to use BR tags instead of P tags. It’s not actually because we’re fastidious about using the correct semantic HTML, though obviously we do recommend that, it’s because a lot of concepts that user’s expect simply aren’t possible to implement sensibly if you don’t use the correct paragraph level elements.

Take for example, a simple function like alignment. In Word and any other sensible editor, when you click the right align button, the current paragraph becomes aligned right. Which pretty clearly highlights the problem – if you don’t have paragraphs, what should become aligned? Typically what happens is the entire document, being one paragraph, gets aligned right and user’s unsurprisingly complain. So why not just change the alignment of the current line? Think about it in HTML terms, if you have:

Line 1<br>
Line 2

Where do you apply the text-align style exactly? You can’t apply text-align to inline elements so:

<span style=”text-align: right;”>Line 1</span><br>
Line 2

doesn’t work. Further, we’ve been told that inserting P tags isn’t allowed, so we can’t just make it:

<p style=”text-align: right;”>Line 1</p>
Line 2

because that would introduce “extra whitespace”1{#footlink1:1283780342216.footnote}. So the only option is to insert a DIV tag which makes the HTML structure quite complex. DIVs aren’t just a meaningless element, they add structure to the document and the editor can’t tell which DIVs are important structure and which are just pretending to be paragraphs2{#footlink2:1283780468469.footnote}.

This problem crops up in a huge number of different places – applying headings, style classes, lists, indenting and more. All these special cases need to be handled, adding to the download size for the editor and reducing performance – not to mention taking up a huge amount of development time that could have been put into something more useful.

WYSIWYG editors do such a good job of hiding the way that HTML and CSS work, that people often forget that in the end we’re still trying to generate high quality, standards-compliant HTML output. We’re limited by what those standards and browsers can actually do, so removing important concepts like paragraphs makes it incredibly difficult to create an editor that works intuitively.

Ultimately, it’s not that we developers don’t want to support your use case, it’s just that the restrictions you’re asking us to abide by dramatically reduce our ability to deliver a high quality authoring experience.

1 – which can and should be removed using CSS in the first place ↩

2 – remembering that what was once an unimportant DIV may become important at some point because of a change to scripts or CSS that the editor isn’t aware of ↩