Since I last published an article here, I have encountered several situations where the styling options afforded by CSS have proven insufficient to meet the demand. Such situations can often be resolved with the help of additional identifiers that distinguish the relevant elements from other content. In practice, this means that users must use element classes in such situations.
This piece will address some of such limitations. I will also address several observations about the use of element classes. One simple inclusion, for example, makes any style sheet for DoX CMS more useful.
When Is CSS Not Enough?
CSS consists of two types of components: selectors and rules.
Should it prove impossible to formulate an appropriate selector for applying a set of rules, further identifiers are required. In the case of DoX CMS, this entails the use of element classes.
In case no suitable rule for some intended change exists, style sheets cannot be used to implement that detail. For example, CSS only allows content to be removed at the level of designated elements rather than parts of content inside them. This means that an action such as removing redundant periods from existing content requires that content to be structured in such a way that such details are contained in elements with identifier values that are reserved only for them.
I will share cases where I have come across at least one of these restrictions below. I will also discuss several other limitations for applying style sheets.
Image Layout in Tables
At this time, CSS does not allow selectors that apply to elements higher in the content hierarchy based on the elements they contain at lower levels of the hierarchy. Specifically, the ‘:has()’-selector that this requires is a part of the development roadmap for CSS and at this time, Safari is the only browser that supports it.
This restriction is an issue when a layout rule should be targeted at table cells that contain (only) images.
In the LW-DITA format that DoX CMS largely applies, each table cell contains a p-element by default and any images must be embedded inside them. This makes it impossible to target an image that is immediately inside a table cell since both cells with text and only images also include a p-element for that content. CSS also does not support specifically targeting p-elements that have an image as their only content.
It is possible to use rules such as specifications for maximum dimensions for images that are inside tables. Their layout such as their horizontal alignment, however, can only be specified in relation to the p-elements that contain them. Because a selector cannot be made selective about whether a p-element contains (only) an image, the layout for just images cannot be specified without the use of additional identifiers.
Technically, I did manage to find a way to fulfil a customer’s request that ‘images on the leftmost column are aligned to the left and images on the rightmost column are aligned to the right’ without the use of element classes. The implementation with which I managed to do this is awkward enough, though, that it provides a good illustration of how it is sometimes best to accept that CSS has its limits and to use element classes to support it. This solution also only works on the condition that images are only added to content inside tables as the sole content of their respective table cells.
tr > td:first-child > p > img {
float: left;
}
tr > td:first-child > p {
clear: left;
}
tr > td:last-child > p > img {
float: right;
}
tr > td:last-child > p {
clear: right;
}
tr > td:first-child > p::before, tr > td:last-child > p::before {
content: ".";
color: rgba(255,255,255,0.0);
display: inline-block;
width: 0px;
}This piece of code moves the images inside the p-elements of a table’s first and last column outside them. In the leftmost column, the images are moved to the left and in the rightmost column, they are moved to the right. The p-elements in question are also subject to a rule that sets their content in line with the upper edge of an image that has been moved like this. Otherwise, the lower edges of images would be in line with their lower edge. This rule only functions properly when said p-elements also have some other content, however. As such, an invisible period with a with of zero has been added to all p-elements in either the first or the last column of a table. It acts as the content that is required for to properly align the image vertically without having any effect on cells with text despite also being a part of them.
An alternative to this would have been to include element classes for the tables where either the first or the last column is reserved only for images. When such an element class is used on the whole table, any associated rules can be targeted at either its first or last column. This also allows you to still use images alongside other content.
Continuous Numbering for Lists
Unlike HTML which has a separate ‘start’ attribute, DITA does not in itself let you start numbered lists with different values. Thus, when lists that continue across the boundaries of one element and into another are needed, they must be implemented through the use of a style sheet.
CSS also supports no rule that has this effect, though. Instead, you must use a combination of rules that start a separate counter and then replace the numbering of affected lists with the values of said counter. If this counter is not reset for each such numbered list, the numbering that uses it remains continuous until its next reset point.
In terms of selectors, this solution entails that the reset point must be specified in relation to elements that contain the affected sets of lists. In the example provided below, this has been done in relation to tables. This necessitates the use of element classes unless such behaviour is intended as the default for how lists are numbered. Implementing them like this is possible and our support can help customers with more information on it in response to any queries on the subject. The method illustrated below only works with tables that use suitable identifiers. Acknowledgement for this solution belongs to our former system developer Oskari Torikka, even though I have made modifications to the selectors to only target numbered lists on the first level of organization. I also added a separate element class to reset numbering purely for the sake of improving the user experience. I figured that it might prove unintuitive to use the same element class on both an upper level element and a lower level element that it contains to reset such custom numbering.
[doxelementclass~="ContinueNumbers"] {
counter-reset: splitcounter;
}
[doxelementclass~="ContinueNumbers"] td > ol > li {
list-style-type: none !important;
}
[doxelementclass~="ContinueNumbers"] p {
display: inline;
}
[doxelementclass~="ContinueNumbers"] td > ol > li:before {
counter-increment: splitcounter;
content: counter(splitcounter) ".";
}
[doxelementclass~="ContinueNumbers"] td > ol > li {
text-indent: -1.3em;
}
[doxelementclass~="ContinueNumbersStartAgain] {
counter-reset: splitcounter;
}Thus, while this feature can be implemented, in practice, doing so is fully reliant on the use of suitable element classes. It is also necessary that the element class in question is used on an element higher in the content hierarchy and that all the lists with continuous numbering are embedded inside that element. This feature cannot be applied directly to the list elements themselves because no suitable rule for that is available.
Spacing for Titles’ Number Identifiers in the Table of Contents
In the content itself, it is possible to freely space out the number identifiers associated with topic titles because the document template that we use includes the identifiers that doing so requires. Unfortunately, the same cannot be said of the table of contents. In there, the number identifier and the title are only separated with an empty space and they are both part of the same element.
We have planned an update to the document template in question, and it would add elements with distinct identifiers to as many positions controlled in an automated manner by the system itself as possible. An outline exists for such updates to the current document template. Since a new document template will require suitable style sheets, implementing it will involve the option to select which document template is used in any given publication.
This fact emphasizes how the structuring of content involves a degree of responsiblity towards accounting for the needs of the style sheet. In terms of automated additions, we have this responsibility to ensure that users have a maximal capacity to style said content with style sheets. However, users ought to also accommodate the limitations of style sheets in terms of how they structure content. For example, image layout cannot be controlled as freely as in MS Word because publications are assembled from pieces of content of varying sizes in different languages and page-specific positions cannot thus be guaranteed. As such, designing documents also involves the need to ensure compatibility with style sheets by ensuring that details such as the positioning of images are suited for changing page layouts.
The Limits of Compilers
It is worth considering how implementing style sheets does not involve a relation simply between the raw content and a style sheet. Using a style sheet to determine the layout for content also involves an interpreter. This relationship between the forms of input and their output is not univocal. Rather, it involves a variety of choices regarding the proper implementation. For this reason, there exist a variety of programs for compiling PDF files, for instance, and they each support different solutions and have different outcomes.
DoX CMS lets users choose between Essential Objects or DocRaptor as the service used to publish PDF files.
These two compilers require completely different solutions for headers and footers, for example. In this respect, the components suitable for Essential Objects — especially together the features of DoX CMS which are compatible with it — are easier for users to manage and arrange. On the other hand, DocRaptor is based on PrinceXML and thus it allows for more flexibility in terms of positioning content in page margins, including horizontal margins. It also allows the use of commands that are unique to PrinceXML such as ‘leader()’ and ‘running()’ which make implementing a layout for the table of contents easier among other things.
Some requests can only be fulfilled when specific compilers are used. The transition from one compiler to the other, on the other hand, may require an encompassing rewrite of prior style sheets (alongside the files for page headers and footers).
Element Classes
One of the examples presented above shows how it is possible to overcome some otherwise unmanageable limitations of CSS. Their primary purpose is to enable additional distinctions which let you target circumstantial rules to only apply under the correct circumstances.
What kinds of considerations are there that should be taken into account in relation to element classes?
Multiple Element Classes on the Same Element
It is possible to apply more than one element class on the same element. They are all values that are added as parts of the value for a single attribute, ‘doxelementclass’. This allows you to, for example, simultaneously apply both an element class like the one presented above to use continuous lists and an element class that hides the frames of a table.
Enabling the same element to have more than one element class requires the use of specific formatting in the style sheet as well, though. Since they are related to an attribute value, the equals sign results in checking whether the total values involved are equivalent. They would thus require that the rules for element classes have to be specified separately for each combination.
Such unnecessary effort can be readily avoided, though.
Acknowledgement for this solution belongs to our system designer Atte Sairanen.
You only need to format element classes in style sheets as follows: ‘[doxelementclass~=”ElementClassTitle”]’. The ‘~’ sign before the equals sign entails that the selector only requires that the listed value is included in the total value for said attribute.
We recommend that this format is used for element classes by default. This ensures that they will function when more than one is applied to the same element, and the format has no potential side effects. Most older instances currenly include the specifications for element classes without the ‘~’ sign, in the format ‘[doxelementclass=”ElementClassTitle”]’.
These specifications can be written in other formats when necessary, too. If element classes are systematically formulated in such a way where they share keywords at the start or at the end, there are formats that let you refer to such sets of element classes. Further information on this is available here.
The Content Hierarchy and Element Classes
Element classes need not be applied directly to the elements that will be affected by the associated layout or styling rules. They can be used on elements higher in the content hierarchy and the associated selectors can then specify lower level elements below said elements.
This lets you avoid specifying the settings for multiple elements in a sequence one at a time. Tables, for example, may require that specifications are applied to several rows or to each cell in a specific column. Even though such details may appear to be part of the layout or styling of the table as a whole, the specifications themselves must be applied to its individual parts instead. The same method can also be applied to section elements, for example, if multiple elements of the same type in proximity must look the same but different from the norm.
This only requires that you specify the element with an element class as a higher level element in the associated selectors. The rules need not be applied directly to the elements with the element class. Instead, they can be specified for appropriately defined lower level elements.
Overriding
CSS applies the last value for a given rule provided in a selector of the same level of specificity. As such, style sheets should be ordered to first provide the rules for elements that are higher in the content hierarchy and then exceptions involving elements lower in the content hierarchy. This order of priority can be overridden with the qualifier ‘!important’ but overusing it makes style sheets unpredictable in terms of which rules will ultimately apply. Since element classes are intended as overriding specifications, though, this qualifier should be used with them.
The specifications for element classes are thus best included towards the end of a style sheet. It us also a good idea to use the qualifier ‘!important’ with them such as in ‘font-size: 8pt !important;’ to ensure that the associated rules will be overriding.
Summary
The layout and styling for structured documentation is inevitably reliant on the use of style sheets because such content is compiled rather than handcrafted page by page. However, style sheets have their limits in terms of what they allow. For example, image layouts cannot be specified in terms of their position on a page and dividing content around page breaks must be based on general rules rather than situational considerations.
Such limitations can result from (1) the limits of formulating selectors, (2) the absence of suitable rules, (3) misstructured content or (4) the constraints of the selected compiler.
In the case of selectors, such issues can largely be remedied with the use of further classifications. In DoX CMS, this entails the use of element classes.
When more than one element class will be applied on a single element, the fomat for selectors must be as follows: ‘[doxelementclass~=”ElementClassTitle”]’. The ‘~’ sign ought to be added to the selectors related to pre-existing element classes as well because of this.
Element classes need not be directly applied to the elements that the associated rules will target. Selectors that include element classes can target elements inside the elements to which the element classes have been applied.
Since element classes are used to specify exceptions, you should ensure that their rules are overriding. The most reliable means to achieve this is to use the qualifier ‘!important’. The use of this qualifier should be restricted only to element classes to ensure that they will operate properly. It is also a good idea to leave element classes for the end of a style sheet to make their rules the last say that will apply even when the qualifier ‘!important’ is in use elsewhere.