All software has problems from time to time and to help track them down developers often include debugging functions in their products. EditLive! includes such a function to enable our support team to track down the cause of any problems, but in the past developers have had problems enabling it in the Swing SDK1. There are two common causes for that:

1. We made enabling debugging in the Swing SDK too hard.
2. Developers didn't include a simple way to enable debugging without having to recompile their software.

For the first problem, we've made improvements to help people out in the future. So with recent builds you can simply call ELJBean.enableDebugLogging() to turn on debugging. If you're using an older build you'll need to set the appropriate system properties (which is exactly what the enableDebugLogging method does for you).

The solution to the second problem depends on how you deploy your application and requires a bit of work on the developer's part. If you already have a debugging mechanism in your product, the best thing to do is to enable EditLive's debugging whenever your normal debugging is enabled.

If you don't yet have debugging in your application there are a few simple ways to expose the debugging switch to users:

• For applications started from the command line provide a command line option like -debug to enable debugging.
• For applications started from WebStart, you can use a command line option by adding an argument tag within the application-desc element of your JNLP file.
• For standalone applications you could:
  • Provide a separate launch script which enables debugging (eg: application.exe and application-debug.exe)
  • Check for the presence of a particular file as a signal to output debugging information (eg: the user creates a application-debug.txt file in their home directory)
  • Provide a user preference in your GUI. This will only take effect after restarting your application unless you're using a recent build of EditLive!

You should make sure and test that logging enables correctly just like any other part of your application - there's nothing worse than realizing your debugging is broken just when you really need it.

1 - when using EditLive! within a browser, the JavaScript SDK has always provided a simple setDebugLevel function. ↩

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.

One of the biggest challenges with building a WYSIWYG HTML editor is handling the fact that HTML doesn't provide any guarantees for how things will be displayed. Different browsers and different platforms all render things slightly differently and nearly all browsers provide preferences that let users adjust the way pages display. While this can be frustrating if you're trying to make your site pixel-perfect, it's actually a really important feature as it allows users with limited vision to increase the font size for web pages or to choose a font that's easier for them to read. Fortunately, EditLive! provides a number of options to help your users create content that works well for everyone and fits into your site design.

Since the most common difference between browsers is the size of text, let's take a look at EditLive!'s font size options. If you haven't changed the default configuration file, the font size options are most likely 7pt, 8pt, 10pt, 12pt, 14pt, 18pt and 24pt. These are familiar font sizes for users and make them feel at home, but if the pt sizes were actually used in the HTML it would negate all the accessibility benefits of HTMLs variable font sizing. Instead, the sample configuration inserts relative font sizes that for the vast majority of users render at about those point sizes. Users who have adjusted their browser preferences will still get the benefits of the text being sized so they can read it easily. The configuration to achieve this is:

<toolbarComboBox name="Size">
  <comboBoxItem name="1" text="7pt"/>
  <comboBoxItem name="2" text="8pt"/>
  <comboBoxItem name="3" text="10pt"/>
  <comboBoxItem name="4" text="12pt"/>
  <comboBoxItem name="5" text="14pt"/>
  <comboBoxItem name="6" text="18pt"/>
  <comboBoxItem name="7" text="24pt"/>
</toolbarComboBox>

If you'd like your users to be aware that the font sizings are relative, you can easily change the way the options display just by changing the "text" attribute. For example:

<toolbarComboBox name="Size">
  <comboBoxItem name="1" text="Tiny"/>
  <comboBoxItem name="2" text="Rather Small"/>
  <comboBoxItem name="3" text="Normal"/>
  <comboBoxItem name="4" text="A Bit Bigger"/>
  <comboBoxItem name="5" text="Kinda Big"/>
  <comboBoxItem name="6" text="Large"/>
  <comboBoxItem name="7" text="Gigantic"/>
</toolbarComboBox>

If however, we want to change what gets inserted into the HTML when on of the options is selected, we change the "name" attribute. So to use specific pt sizes:

<toolbarComboBox name="Size">
  <comboBoxItem name="7pt" text="7pt"/>
  <comboBoxItem name="8pt" text="8pt"/>
  <comboBoxItem name="10pt" text="10pt"/>
  <comboBoxItem name="12pt" text="12pt"/>
  <comboBoxItem name="14pt" text="14pt"/>
  <comboBoxItem name="18pt" text="18pt"/>
  <comboBoxItem name="24pt" text="24pt"/>
</toolbarComboBox>

You can put whatever options your users need, including a mix of relative and absolute font sizes and you can always add extra items or remove items that you don't need.

The latest early access builds of EditLive! now make integrating even easier by automatically detecting the download directory and providing a default configuration file. Since the very first version of EditLive! the JavaScript instantiation code would include the two lines:

editlive.setDownloadDirectory("editlivejava/");
editlive.setConfigurationFile("editlivejava/sample_eljconfig");

However that's no longer needed as EditLive! will automatically detect the right URL to download it's resources from and if you don't specify a configuration file it will use the sample_eljconfig.xml configuration file.

You can of course continue to set the download directory and configuration file but you no longer need to. Below are some best practices to make the most of these latest changes:

• Don't set a download directory. It's simpler to leave EditLive! calculate the right URL and it avoids potential errors.
• If you don't need to make any changes to the configuration, don't set a configuration file and simply use the default. This avoids the potential for specifying the URL incorrectly and getting errors.
• If you do modify the configuration file, make a copy in a separate location and instruct EditLive! to use your version with setConfigurationFile or setConfigurationText. By making your own copy instead of modifying the sample, you remove the potential for overwriting your modifications when you upgrade EditLive!
• If possible, use setConfigurationText instead of setConfigurationFile to improve the editor start up time. With setConfigurationFile, EditLive! must wait while the configuration file downloads.