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…

The new Ephox Enterprise TinyMCE site has now gone live, a result of our new partnership with Moxiecode, the company behind everyone’s favorite open source editor TinyMCE. I’m really excited about the potential of this partnership and have really enjoyed the opportunity to work with the Moxiecode team so far.

What We’re Adding…

We think we can bring a lot to the TinyMCE community, the things below are just where we’re starting.

Enterprise Grade Support

We’re really proud of the level of support we’ve been able to offer for EditLive! and we’re bringing that over to TinyMCE. TinyMCE gets used in all kinds of mission critical systems where down time costs real money. Ephox’s support packages offer service level agreements to ensure you get help quickly and keep things running smoothly.

More Resources for TinyMCE

Ephox is dedicating resources to help develop TinyMCE, improve it’s quality, answer questions on the forums (even for the free LGPL version) and generally help make TinyMCE even better.

We’ve already had a number of patches accepted into the main TinyMCE branch and are using our build farm to run TinyMCE’s tests across a wide range of browsers and platforms to help the Moxiecode team keep quality levels high (check out the results here). You’ll also see Ephox folk popping up in places like the TinyMCE forums to answer TinyMCE questions.

Quick and Easy Commercial Licensing

If you don’t want to distribute changes you make to TinyMCE under the LGPL or prefer a more traditional commercial software license for whatever reason, you can quickly and easily buy one straight from our web store, with our without a support package.

Express Edit

We’re currently working to update our “Express Edit” feature of EditLive! to make it simple to integrate both EditLive! and TinyMCE with the same set of APIs and have the most appropriate editor for the situation load. Express Edit has been around for a while, but with the power of TinyMCE we think it’s time has really come to shine. With Express Edit you can offer all the advanced features of EditLive! but know that if Java isn’t available or you just need a lightning fast editor to make a quick change you’re users will have TinyMCE available too. Basically, you get the best possible editor for any situation.

Committed To…

In case you were worried there’s a few things that we’re absolutely committed to:

EditLive!

We still see EditLive! as being Microsoft Word for the web. It’s a full featured, enterprise editor that dramatically improves author productivity and assists them in creating higher quality content. EditLive! has been the leading online editor for many years now and we are going to continue improving it as fast as we can. There’s plenty of great stuff coming down the pipeline for EditLive! including of course an improved Express Edit.

Open Source

Ephox as a company may not have had much to do with open source in the past, but most of the people working for Ephox have and we’re big fans. Now we get the privilege of working with the vast TinyMCE community and that’s really exciting.

Most importantly, TinyMCE is absolutely still available under the LGPL, Ephox is even providing a direct download link from our site to ensure everyone knows they are quite welcome to take TinyMCE and use it for free. The only difference between the LGPL community edition download and the commercially licensed options we’re providing is the license information.

TinyMCE

Ephox and Moxiecode are working together closely on this venture. Ephox Enterprise TinyMCE is a distribution of TinyMCE, much like projects such as Debian include other open source products. Like Linux distributions we may find and need to fix problems with TinyMCE which causes our distribution to vary slightly until those changes can flow back upstream. To avoid any confusion, Ephox distributions of TinyMCE have an extra component to the version number, for example the current TinyMCE release is 3.3.6, so the current Ephox distribution is 3.3.6-170. This makes it clear which base version of TinyMCE is being used, that it’s been modified (even if only to add our naming) and which build from Ephox it is.

We’ve also called our distribution “Ephox Enterprise TinyMCE”, this is mostly a marketing thing but again it helps to avoid confusion in case there are fixes in our build that haven’t yet made it back upstream.

Questions? Comments?

If you have any questions, concerns or comments feel free to post them below or get in touch with me directly at adrian.sutton@ephox.com or by phone on +44 7 525 806 170 and I’ll do my best to get you an answer.