One of the most difficult situations to work with is when your output needs to be rendered using Flash. The HTML support in Flash is absolutely horrendous – worse even than in most email clients. Contrary to popular belief, Flash does support P tags. You will however need to ensure the text field is set to multiline. The BR tag is also only supported in multiline fields. The problem most people hit is that Flash doesn’t support the margin-top and margin-bottom attributes so you can’t get rid of the blank line between paragraphs.

The list of HTML tags supported by flash is very short, so you will need to disable most of the editor functionality, however since flash does support things like bullet lists, for the most intuitive editing experience, it’s best to use P tags to break up the paragraphs rather than BRs.

Instead of avoiding P tags to avoid the extra white space, use a two part approach. In the editor, use P tags for paragraphs, and include the CSS:

p { margin-top: 0; margin-bottom: 0; }

Then before passing the HTML into Flash, filter it to replace <p> with <span>1. Store the original content, with the P tags, in the database so that they are still present when the user goes back to edit existing content. You will need to disable any formatting that applies to the paragraph element – most notably alignment. There is no way to support alignment without a block tag and P is the only available block tag within Flash. If you need alignment support, you will have to use P tags and put up with the extra white space. Lists will still work correctly2 because the editor is working with the P tags, and the Flash renderer

In any case for Flash you will need to disable a lot of functionality to ensure only the supported elements are inserted. Essentially, bold, italic, underline, font face, font size and font color, images and hyperlinks. There are a few other CSS properties supported, but still very limited.

The limitations in Flash do provide significant challenges to providing a powerful and intuitive HTML editor, but the user experience will almost always be better if the editor works with P tags, and then they are replaced before rendering, using CSS within the editor to ensure consistent rendering. In all cases, it is vitally important to heavily restrict the functionality that is available in the editor. If at all possible, avoiding the need to render HTML within Flash is usually the best option, but not always feasible.

1 – Flash 9 doesn’t support the DIV tag, otherwise that would be the ideal alternative. ↩

2 – tables are not supported by Flash anyway↩

One of the common reasons people want to avoid P tags in content is because the field is designed to hold just a single paragraph, so having multiple P tags inside the content would break the template layout when it’s rendered. Usually the template renders the content as something like:

<p><%= fieldContent %></p>

In that case, where the output is the only thing within the paragraph, the best solution is to leave the paragraph tags in editor content and remove them from the rendering template. That gives the editor the context it needs to work well and avoids a lot of potential problems with rendering the content. If however, you’re including some extra content in the same paragraph then the situation is more difficult, e.g. your rendering template is more like:

<p>Summary: <%= fieldContent%></p>

In this case, you need to include the P tags within the rendering template and need to ensure that any functionality in the editor which requires inserting a block tag is disabled. Many people think that just switching to insert BR on enter will achieve that, but it’s quite a long way short. For example, if the user creates a list, the template would output:

<p>Summary: <ol><li>Content</li></ol></p>

which is invalid. Similarly since alignment must be on a block tag, it would create:

<p>Summary: <div style=”text-align: center;”>Content</div></p>

which is also invalid. Headings, tables, margins, blockquotes and many other functions will cause these problems. Instead of trying to disable the problematic things, it’s much simpler to only enable the inline formatting options that you need – it should be very limited since you’re only editing a small snippet of content:

• Bold
• Italic
• Underline
• Strike-through
• Font face
• Font size
• Font color
• Background color
• Superscript
• Subscript
• Images
• Hyperlinks

Depending on your editor, there may be a couple of other functions that can work, but most things will need to be disabled. Notably, all these functions work regardless of whether there’s a P tag present or not, because they work “inline”, directly on the text.

Once you’ve restricted yourself to these functions, it’s usually ok to switch the enter key to insert a BR instead of a P, but carefully consider whether having line breaks in the content makes sense with your template anyway. If you want users to be able to insert multiple paragraphs, you should design your template to let them use P tags rather than using BR as a substitute. Consider using a plugin to disable the enter key altogether since the field is designed for a single line response.

Finally, using a plugin or validation when the user submits, check that the content has only one paragraph and isn’t too long to fit within your template. With many editors it will be better to work with the content inside a P tag within the editor and then use JavaScript or server-side filtering to remove them when saving the content.

The bottom line is that when restricting content to a single paragraph, you should ensure that all functionality which works at the paragraph level is disabled in the editor as it cannot be made to function correctly. You should also carefully consider whether users should be allowed to insert line breaks in the content and if they are, whether these are really paragraphs and users would be better served with a slight change to the rendering template, allowing them to use the full functionality of the editor.

One thing that many people don’t realise, is that the distinction between paragraphs and line breaks isn’t unique to HTML. In fact, it’s a distinction that people have been working with quite happily for a very long time – Microsoft Word has supported the two concepts right from it’s very first version. With the more recent versions of Word, the default paragraph spacing is zero, so line breaks and paragraphs look the same, even though there is an important semantic difference. You can still see the difference if you show the non-printing characters:

The first line is a paragraph, note that it ends with the invisible paragraph marker character (¶). The second line ends with a line break character instead (¬) so the end of the line is not the end of the paragraph. There are actually only two paragraphs in this document. You can see this in action when we position the caret at the end of the text and apply a heading style.

The heading style is a paragraph level style, so it applies to the entire paragraph, even though there’s a line break. In fact, if you save that original document as HTML, you get the structure:

<p>Paragraph 1</p>
<p>First line of paragraph 2<br>
Second line of paragraph 2</p>

Just like any good HTML editor would create. You can try this yourself in Word, typing enter will create a new paragraph, typing shift-enter will instead insert a line break. The same keystrokes apply to most HTML editors as well.

Rendering Differences

When copying and pasting content from Word into a HTML editor, it’s possible that there will be extra space added between each paragraph. This is a result of having different settings for what Word calls paragraph spacing (called margin-top and margin-bottom in HTML/CSS).

With the more recent versions of Word (last 10 years worth on Windows, last 5 years or so on Mac) the default is to have no paragraph spacing which effectively makes a paragraph marker and a line break (P and BR) look the same, simply moving to the line immediately below1. In any case, in browsers the default is to apply a 12pt paragraph spacing through the CSS margin-top and margin-bottom attributes which are set in the browser's default stylesheet.

So to get the same rendering as Word, you should keep using paragraphs but add the CSS:

p { margin-top: 0; margin-bottom: 0; }

Make sure you add it both to the rendered page and to the styles used by the editor. There is more detail on this and other ways to make HTML behave more like Word in the Ephox article, Making EditLive! Content Behave More Like Word, which is applicable to all editors.

1 – I've never quite understood why they made this change as it has led to users inserting a new paragraph by pressing enter twice which effectively adds an empty paragraph to get the paragraph spacing they want. ↩

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. 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.

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 ↩

One of the greatest frustrations for anyone who develops an HTML editor is the constant supply of people who are convinced they want to use BR tags instead of P tags. Most of these are just people who don’t want “double spacing” and they’re happy once you give them the magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 0;
}

The other group however are people writing HTML emails who insist that P tags are completely incompatible with some email clients and cause rendering problems. At one point it seems that Yahoo! Mail really did strip them entirely but now it just applies a different default CSS styling (ironically, the magical CSS above that removes the extra spacing). So if you naively use P without specifying the padding you want, some clients will display a blank line between paragraphs, others, notably Yahoo!, will push all the lines immediately under each other. The solution is of course the opposite magical CSS incantation:

p {
  margin-top: 0;
  margin-bottom: 1em;
}

Solved right? Nope. This runs straight into the where the heck do I define styles? problem. In HTML, it should be:

<html>
<head>
<style>
p {
  margin-top: 0;
  margin-bottom: 1em;
}
</style>
</head>
<body>
…
</body>
</html>

However while this works in some clients, it has no effect in most. Instead, the common wisdom is to move the style tag into the body tag:

<html>
<head>
</head>
<body>
<style>
p {
  margin-top: 0;
  margin-bottom: 1em;
}
</style>
…
</body>
</html>

Which works almost everywhere. Enter GMail. GMail never respects the style tag, only inline styles. So now you need to write your paragraphs as:

<p style=”margin-top: 0; margin-bottom: 1em;”>…</p>

Thankfully you can use the margin shorthand if you know what you want the left and right margins to be as well:

<p style=”margin: 0 0 1em 0;”>…</p>

I would strongly recommend using embedded styles while editing and then just use post processing to inline all the styles – Premailer can do that for you.

As far as I can tell, there is no need to avoid P tags in email anymore and sampling a number of emails from various clients that happened to be in my inbox, they turned out to appear in emails from a few different clients though that’s far from scientific and it was still intermingled with a lot of <br> and <div><br></div> hacks. I would be very keen to hear from anyone who knows of an email client that cannot be made to render P tags correctly.

With a bit of luck we may be able to start moving away from the horrific abuses of <br> tags…