Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
If you're new to Paligo, you might be wondering how to add sub-headings to your topics. In this article, I'll show you the various ways of creating sub-headings in your output and explain the pros and cons of each.Let's start by making it crystal clear what sort of page structure I'm talking about. What we want to achieve is a page in the output that contains a main heading and some text, followed by sub-headings with text, like this:
So the area I've marked in yellow is what we need to create.This is going to be quite a long post as I'm going to try and share everything I have learned about sub-sections. You can use the links below to navigate to the various parts:
It is difficult to recommend using the <bridgehead> element. Yes, it allows you to have a sub-heading and heading in the same topic, but it is less useful than the <section> element.Really, you should only use the <bridgehead> element if:
That's all there is to it. You now have a topic with its main heading (Title) and a sub-heading (bridgehead).Bridgehead Pros and Cons
It allows you to add a heading and sub-heading to the same topic. This can be easier for authors to manage the content, especially if a sub-section is unlikely to be reused.It can be set to any level, so does not have to follow the hierarchy of heading levels.
Limits content-reuse. The and the rest of the sub-section are tied to the topic that contains them. To reuse the sub-section as a whole, you would have to turn the sub-section into a reusable component.Cannot be controlled via the toc level or chunking options.Is not a hierarchical heading, and so has no structural relationship with other headings or content. This limits the way it can be processed for your output.
Every topic in Paligo is a section (it uses the <section> element). But you can create sub-sections inside a 'main' section too. The recommended way to do this is to use the <section> element. This will keep your sub-section in the same topic as the main section and also follows the hierarchical structure of the headings (unlike the bridgehead element). And if you discover you do want to reuse the sub-section at a later date, you can always turn it into an informal topic.
Using sections for sub-sections creates a similar structure (in the code) to using separate topics for sub-sections. Each section of your content is enclosed in its own <section> element.Section Pros and Cons
It allows you to add a heading and sub-heading to the same topic. This can be easier for authors to manage the content, especially if a sub-section is unlikely to be reused.Follows the heading hierarchy levels, so will use the appropriate heading style in the publication's table of contents.
Limits content-reuse, but not as much as the bridgehead element does. A sub-section can quickly be turned into reusable content, and as it has a title element, structurally, it is already the same as a separate topic.
If you have a sub-section that might need to be re-used, you should consider creating separate topics. This can seem strange at first, especially if you are used to creating content in Word, or even some other topic-based systems, like Flare. But it does offer the most flexibility when it comes to content reuse.The idea is simple. Instead of having your main section and sub-sections in the same topic, you separate them into their own topics. Then you organise them into the hierarchy you want in the Publication's table of contents. In the image below, the three sections would all be created as unique topics.
By default, this will produce a HTML5 output that has a single page that contains the main section (in the example, 'Set the Clock') and the sub-sections ('Set the Time' and 'Set the Date').There are various options for controlling how the hierarchy levels are used in the HTML5 output. You can find most of them on the Layout editor, which I'll cover next.Section and Chunking Pros and Cons
The best option for content reuse.Sub-sections can be reused independently of main sections as they are independent topics.Follows the heading hierarchy levels, so will use the appropriate heading style in the publication's table of contents.
Your sub-sections are not in the same topic as the main section. This can make it more difficult for authors to manage, especially if they are not used to topic-based writing.
When you have sub-sections, you'll need to consider how they are going to appear in the table of contents menu in your HTML5 output. Paligo has several options for managing their appearance, and most of them are on the Layout editor.
Let's look at the options that affect the table of contents menu. First up, is the TOC section depth.
The TOC Section Depth setting is pretty self-explanatory. It controls the level of sub-headings that are shown in the table of contents menu in your HTML5 output. The default setting is 3, which means once the table of contents menu is 3 levels deep, any deeper levels will not be shown. The 'deeper' topics will appear in searches, but cannot be accessed from the menu.
This option is useful if you have a hierarchy of topics, and some of them contain sub-sections. It allows you to stop the sub-sections from appearing in the table of contents.For example, let's say you have a Publication structure like this:
This would produce a 2-level table of contents in the output like this:
Now, let's say that the 'Set the Time' topic also contains a sub-section called 'Set the Time Adjustments'. Should the sub-section be included in the table of contents as a menu option or should it be excluded because it is a section inside a topic, rather than a topic in its own right? By default, sub-sections within topics are included in the table of contents (note that this refers to 'proper' sub-sections and not bridgeheads).
To prevent sub-sections in Topics being shown as options in the toc menu, enable the Only include chunks in TOC option.
Use the Chunk Section Depth to control the level at which chunking occurs. Chunking means that once the structure reaches a certain level, any deeper topics will be added to the end of a parent topic.For example, let's say you have a five-level structure and the TOC level is set to 3. This means that your level 4 and 5 topics will not be in the table of contents menu, but will be on seperate pages. That can make it difficult for your readers to find the content, so one option is to set the Chunk Section Depth to 3. This causes the level 4 and level 5 sections to be added to the end of their parent topic (which is a level 3).
In DocBook XML, there is no distinction between a section as a topic and a section as a sub-section, and so every section becomes its own web page. Paligo uses a customisation of DocBook that works differently - Paligo can tell the difference between a topic and a sub-section inside a topic.
The Legacy Section Chunking setting allows you to apply bog-standard DocBook to your content, so that every section is treated as a topic. Typically, you would only enable it if you had an old DocBook project that you were using in Paligo.
Okay, so those are the Layout options that affect the TOC structure. But there is one more thing to look at - applying chunk controls on a per topic basis.
You can use the Layout options to apply general toc depth and chunking rules. But you can also control chunking for each individual section element too. This is useful if you have some sections that need to be handled slightly differently to the rest. (You know, those *special cases* that cause us authors so many problems).
To make a section appear as its own web page (a chunk):
Note that the xinfo:chunk property takes precedence over the Layout settings.Right, I think that's everything I can tell you about sub-sections in Paligo. If you have any questions, please leave a comment.
Craig Wright is an experienced technical writer based in Chesterfield, UK. He hates writing about himself in the third person, so I shall stop now.
Always interested in new content writing opportunities. Remote working preferred.
Registered Number: 08029184
Straygoat logo design by Bristol graphic designer, Nik Jones.
© Straygoat Writing Services Ltd.