This section describes some basic principles that will help you to use styles more efficiently. Once you understand styles the way you use them is also a question of your personal working preferences. For example, some people prefer to have a small, more manageable set of styles and pay for this convenience with a little more manual formatting work. Others prefer to have a large and almost complete set of styles that allows them to control virtually all their formatting by editing styles.

Separating formatting and content:

One of the basic purposes of dynamic styles is to allow you to separate formatting and content. Theoretically, if you do this completely all the formatting in your entire project would be controlled by styles and you would be able to change the appearance of everything just by modifying the styles. In the real world all projects will normally contain a certain amount of manually-formatted text. For example bold and underlining to emphasize individual words and passages, and individual manually-formatted paragraphs and sections for which it would not be worthwhile to create one or more special styles.

The "many styles" and "few styles" strategies:

The number of styles you really need depends mainly on the amount of manual formatting you are willing to do. There are two basic approaches to this, the "many styles" strategy and the "few styles" strategy:

Many styles:

If you want to control all your formatting with styles you will need quite a large number of styles for each project. Most of these styles will not be unique, they will be variants of other styles. For example you will probably want to have several variants of the Normal style used for standard paragraphs with indents and other modifications.

Few styles:

The "few styles" approach uses exactly the opposite strategy. Here you would use a single style for each basic paragraph type, heading type and so on. With this strategy you don't create any variants of these styles: If you want to use a variant, for example with an indent, you must then apply the indent manually while you are writing and editing your topics.

This approach results in a much smaller list of styles that is easier to manage. It works if you are quite clear about what formatting you are going to apply manually. However, you must really be absolutely sure that all the manual formatting you apply are things you are not going to change. In the case of indents, for example, this is generally a relatively safe assumption.

You can still make global changes to your styles when you use this method, but any manual formatting you have applied will not be changed when you change the style definitions. (Manual formatting always has priority over style formatting.)

Style families

No matter whether you use many or few styles it is always advisable to organize your styles in "families", both by name and by inheritance.

Style name families:

This is simply logical and makes your styles easier to identify and find. It makes sense to create families of headline styles called Heading1, Heading2, Heading3 and so on. Then they all appear together in the list and you know what they are for. If you want you can also include some key information in the names. You can organize your other style groups like body text and so on in the same way.

Remember that you can rename your styles at any time!

Don't hesitate to rename your styles if you need to! Help+Manual automatically updates all style references so you can rename them to improve your styles organization whenever you want.

Style inheritance families:

Styles inherit properties from the styles they are based on. If you base groups of styles on a common parent style you can make changes to the common properties of the entire style group by editing the parent style.

For example, you could base all your headline styles on the standard style Heading1, if you want them to be similar to Heading1. If you don't want them to be similar to Heading1 you could create a new parent style for the headlines you want to use in your topics, and base your other headline styles on that.

The same applies to other groups of styles for text or paragraphs with similar attributes. See About inheritance in styles for more background information on this.

Naming paragraph and text styles

It's advisable to apply a prefix to text styles that automatically distinguishes them from paragraph styles and keeps them together in all the style selection lists, which are sorted alphabetically – for example P_ for paragraph styles and T_ for text styles.

Actually, you only need to use a prefix for one of the two because anything that doesn't have the prefix is automatically identifiable as the other type.

One inheritance tree or multiple trees?

By default all the styles in Help+Manual except the standard Code Example style (see The standard styles) are based on Normal, which is also the style used for standard paragraphs in topics. This means that you have a single style inheritance tree. The advantage of this is that it makes it possible to change attributes throughout your entire project by editing Normal. You can change the standard font in all your styles simply by changing the font of Normal, provided you haven't explicitly changed the base font in any styles. The same applies for all other inherited attributes of Normal.

Creating new style inheritance trees:

When you create a new style that is not based on any other styles you effectively create a new style inheritance tree. The question is, is this an advantage or a disadvantage?

The main advantage of a completely new tree is that it is guaranteed that you can't accidentally change the attributes of styles in the tree by editing Normal or another higher-level style. Many authors use one tree for body text styles and another tree for header styles, for example.

The disadvantage is the same as the advantage: You have to edit the styles in the second tree separately, which means maintaining your styles can be a little more work. But it can be worth it if you find making this division makes it easier for you to manage your project.

It's a question of personal preference:

Ultimately it's a question of personal preference whether you use the one-tree or the multi-tree method. However, it's probably a bad idea to create too many trees, as that can get really troublesome to manage.

If you do use multiple trees it's best to stick to one tree for each main group, for example one tree for body text styles, one tree for header styles (particularly if you use different fonts for headers and body text) and so on.

Using hotkeys

Last but not least, don't forget to assign hotkeys (keyboard shortcuts) to your frequently-used styles! If you spend any amount of time working with Help+Manual (and if you're writing help you will) this can radically speed up your work.

See also:

Text Formatting and Styles (how-to instructions)