This month I travelled around Australia and met with several long term Ephox clients and talked with them about their experiences with EditLive!, what they’d like to see in the product and what’s coming in EditLive!.

Their feedback was very valuable and it’s safe to say that the trip is likely to be the first of many very client focused trips.  In fact, if you’d like to share your own EditLive! experiences, please get in touch with us via the LiveWorks! mailing list, we’d love to hear from you.

One of the things that came up a few times was some inconsistencies between HTML and Word rendering that can cause confusion when users are importing content from Word. There are two simple things you can do to your web site’s CSS to help users out with this.

Firstly, default top and bottom margins.  Users experiencing this issue often complain that, when content is pasted from Word into EditLive! there’s “double spacing” between paragraphs.  This happens because the top and bottom margins on paragraphs in Word are set to 0, but in HTML it tends to be around 6 pixels or so.  The simple solution here is to override the HTML defaults in your CSS by adding something like this:

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

It’s worth noting that you could also fix this issue by changing the top and bottom margins in your word processor’s default document template (normal.dot in Word) to match HTML, but it’s much easier to change this in your style sheet because it’s settings are centrally administered.

The second thing that often confuses people more used to creating content on their desktop rather than online is the nature of HTML tables.  This is because tables in desktop word processors have a single border, whereas HTML tables, by default actually have two borders.  You usually can’t see this because there’s no cell spacing specified.  However, if you look at the table below where I’ve set the cell spacing attribute to 2 you can clearly see the borders.

This is because each cell border is made up of two border lines - the border of the cell and the border of either the table or the neighbouring cell.

Fortunately CSS comes to the rescue again.  In order to make HTML tables behave just like tables in desktop word processors all you need to do is collapse the table borders.  This can be done by adding the following code to your site’s CSS:

table{
        border-collapse:collapse;
}

Which will make your table look more like this (note I’ve not changed the cell spacing here, just applied border-collapse):

And that’s it.  These two simple CSS changes can make a world of difference for your EditLive! users, especially when they’re importing content from desktop word processors.  Just a couple of final things to remember before you start applying this CSS everywhere:

• Remember if you’ve got a CMS often the published CSS is different to the authoring CSS that EditLive! uses.  Make sure you make the required changes to both sets of styles.
• You’ll want to test this CSS in a development/testing environment first to make sure it doesn’t have an unexpected impact on your web site’s layout.
• If you’ve already got CSS specified for the “p” tag and/or the “table” tag just add these properties to what you already have.
• If you add this CSS to the root element style (i.e. not a class style) like I have above, it should inherit across all the other classes you have in your CSS for tables and paragraphs.

Hopefully you’ll find this very useful and if you’ve got any questions just get in contact with us via the LiveWorks! mailing list.

With the improved styles support in EditLive! 6.4 (grab the latest build from early access), and a little CSS, it's easy for users to make their content look great and better engage users. Let's look at a fairly simple example where users can add a set of links to related resources in their document. Currently, users would simply add a plain bullet list which is pretty ugly. For example:

See Also

• LiveWorks! Styles Category
• Driving Consistency With CSS

That does the job, but with the improvements in EditLive! 6.4 and some fairly simple CSS we can make it look much more compelling. The first step is to group the heading and the list together in a group. EditLive! 6.4 provides a simple way to do that - just select them both and choose "Create Section" (the default configuration includes it in the Format menu). In terms of the HTML, this wraps a DIV element around the heading and the list which gives us some extra structure to work with but doesn't change the actual rendering.

That extra structure gives us a great place to add styles to control the see also panel from one place. The goal is that the user can simply select one item from the styles drop down and all of our formatting is applied. Let's start by adding some simple styles to the DIV itself:

div.SeeAlso {
    border: 1px solid #D4D4D4;
    width: 20em;
    margin: 0px 10px 0px 10px;
    float: right;
}

Those styles add a simple gray border, set the width of the DIV to 20em (ems are a relative sizing that's newly supported in 6.4 and is much better for accessibility than using px) and floats the DIV to the right so content can wrap around it. The result is on the right, titled "See Also (2)".

Now we want to make the heading and the list itself look better, but we don't want to make the user apply styles to them separately. Fortunately, CSS provides a descendant selector which fits this use case perfectly. We add the styles below which will automatically apply to the content inside the DIV:

div.SeeAlso h4 {
    margin: 0px;
    padding: 5px;
    font-size: 1em;
    background-image: url(largeTitleBar.png);
    color: #FFFFFF;
    background-color: #5E657B;
    background-repeat: repeat-x;
    background-position: center;
    background-attachment: scroll;
}

div.SeeAlso ul {
    margin: 0px;
    padding: 2px 5px 2px 35px;
    list-style-image: url(bluearrow.png);
}

div.SeeAlso li {
    margin: 0px;
    padding: 3px;
}

div.SeeAlso a {
    font-weight: bold;
    text-decoration: none;
    color: #2B3D72;
}

div.SeeAlso a:hover {
    text-decoration: none;
    text-decoration: underline;
    color: #8599D3;
}

While there's a fair bit of CSS there, it's all standard techniques that web designers are quite used to using for styling content. It also uses a couple of background images to provide nice gradients so that the final result looks like the image on the right. Here's the important elements that make it work well with the editor. Keep these in minds when you develop style sheets for your site:

• Make it easy for users to apply by using a single class on the div element and then apply styles via descendant selectors whenever possible.
• The class name you use will appear in the styles drop down, so make it self explanatory to help users know when to apply it.
• The styles combo is context sensitive so it will show an accurate preview of how the style will look in the current context. So with the stylesheet above, the "Heading 4" entry would appear differently in the styles drop down if the current selection is within a "SeeAlso" div because the descendant style applies. Elsewhere, the default rendering of h4 elements would apply. This lets your users know what things will look like without having to try out each style. You could use this to provide different types of rendering for the header based on different heading levels and the user can pick the most appropriate one.

On many sites, including LiveWorks!, the layout expects that the main content will be included within a particular DIV structure. For example, LiveWorks! sets the background color for the body to a light green and the div#content element to have a white background - expecting that all the content is in the div#content element. This renders fine on the actual web site, but causes problems when editing entries because only the actual entry content is loaded into the editor - not the surrounding content div.

Fortunately, there's a simple way to work around this, that doesn't require you to create a special editing version of your stylesheet or forego styles when editing. First, add an id to your body tag: <body id="body">, since this ID won't be present in the editor any styles you apply to it will only apply to the actual site.

Next, adjust any styles that you want to only show on the website to use #body instead of just body. So for the background color on LiveWorks! we originally had:

body { background-color: #DBEEDD; }

and we change it to:

#body { background-color: #DBEEDD; }

This can work even if the style rules don't apply directly to the body tag. For instance if we wanted to make H1 tags blue on the web site but not in the editor (if you'll excuse the contrived example), we'd start off with the rule:

h1 { color: blue; }

and change it to:

#body h1 { color: blue; }

Then the rule only applies to headings that are descendants of a tag with id="body" so it always applies on the web site, but never in the editor.

When you have multiple authors contributing to a site, it can be a challenge to ensure that the resulting site has a consistent look and feel across all your content. Fortunately, HTML was designed with exactly that problem in mind, allowing you to separate the content from the presentation using CSS. EditLive! automatically detects the CSS styles in your documents which allows your authors to not only see the document as it will be displayed, but also to apply any predefined styles you have created.

Like anything though, with a little bit of effort you can make it dramatically easier for your authors to use your styles like you intended without needing a lot of training. Here's the overall plan:

1. Disable functionality that you don't want your authors to use.
2. Hide CSS styles that your authors don't need.
3. Design your CSS to work with semantic HTML.

Disabling Functionality

If you want your authors to use CSS for formatting, take away the other formatting options so they can't be used. So if you don't want your authors to apply their own fonts to content, remove the font menu. In EditLive! this is as simple as removing the toolbar buttons and menu items from the configuration file. You don't have to remove all the options, for instance you may want your authors to be able to emphasis content by making it bold so leave the bold function enabled. In most cases, I'd recommend disabling:

• font face
• font size
• text color
• highlight color
• underline (underlined text is often confused for a hyperlink)
• alignment

The CSS can still take advantage of all those formatting options, but users will only be using the predefined CSS styles which ensures the look of the site is consistent.

Hiding CSS Styles

Often a site layout has a range of styles that are only used for navigation components around the content like search boxes, menus and side bars. Authors don't need to apply these so they will only clutter up the styles menu and make it harder for authors to find what they need. To avoid this, either use two CSS files - one for the styles that are relevant to the actual content and one for the surrounding navigation. Include both stylesheets via link tags in your HTML pages, but only include the stylesheet that's relevant to the content in EditLive!'s configuration file.

Alternatively, you can specify that a CSS style shouldn't be displayed in EditLive! by adding the property: ephox-visible: false to the declaration. For example:

.myCSSClass {  display: inline;  color: blue;  ephox-visible: false;}

Designing CSS To Use Semantic HTML

To really make it easy for your authors to select the right CSS style, you should design your styles to be based around semantic attributes of the content rather than style. For example, if you wanted news headlines to appear as blue you could define the CSS style:

.blueText {  color: blue;}

This would appear in EditLive!'s styles menu as "blueText" and it could be applied to paragraphs or inline text. Instead, name the style "newsHeadline" to make what it is for obvious. Additionally, since newsHeadlines are always headings, specify the tag type to use. Specifying the tag type not only simplifies the style menu, it ensures that the style is applied to the right tag, making the site more consistent.

h2.newsHeading {  color: blue;}

If you want a style to only be used inline (to the selected text, not to paragraphs), specify the span tag:

span.reference {  font-style: italic;}

You can also use styles for tables, table rows and cells, lists and list items or pretty much any other HTML element. The more specific your CSS styles are, the more likely your authors will use them at the right time and the better your site will look.