These pieces occasionally allude to the option to use the style sheet to specify rules for elements with specific tags. We generally do not recommend that you use such rules. However, this piece will discuss some of the ways in which tag-bound rules in the style sheet can add value to publications.
I will first discuss the general principles based on which you can derive value from adding tag-bound rules to your style sheet(s). The, I will address the associated challenges. Several examples of possible implementations in DoX CMS are included at the end.
Merits
Styles are linked to tags in response to special needs. We still do not recommend that everyone starts to do this. Below, I will detail when styles for tags will provide additional value to justify the effort involved in implementing this.
Distinct categorization
Tags are naturally already placed where they are used to condition content according to the associated categories for purposes of filtering. As such, the associated styles allow you to make these distinctions visible to emphasize and visually distinguish these sections.
Comprehensive deliveries
Tag-bound styles show which parts are specific to a manual when the alternatives have been filtered out when it was published. The greatest benefit from this is achieved when all the content related to different models and so on are part of a single, comprehensive document, though. Perhaps such a manual would be of use for those responsible for authorized service providers to whom it would give access to the information related to all models in one place, for example. The distinctions related to a style make it easier to find the situationally relevant parts.
Opportunities to expand
One type of comprehensive manual involves showing which features the delivery does not yet contain. This can involve attachments to a device or a software licence’s level, for example. Information delivered like this can motivate further purchases because the information on available benefits is readily available to customers. Styles ensure that such information is distinct from information on the features that are already available.
Because these styles are added to all content with the tags in question and because the contents of style sheets cannot be filtered for different publications, we recommend, that the differences in style still show when customers have access to specific parts of the product.
There exists a way to differentiate between deliveries in such a way that such styles are only shown for the tags related to parts that the customer is missing, though. This solution requires separate styles for different deliveries. I will discuss its details further below.
Support for user-controlled content
One available form for comprehensive deliveries are digital deliveries where the users themselves can control the content to suit their needs. This involves the content not being filtered in advance. Instead, users can themselves select which content shows for them at a given time. Styles let users see the borders for different sections. You can make applying such styles one of the settings, too. This lets users get a clearer sense of the sections that will be affected by their choices, for example. Further information on this is available here.
Support reviewers
The primary function for tags is to differentiate content for purposes of filtering it in ways suitable for different deliveries. There are also other ways in which you can use tags. One such way relates to the workflow and filtering list views. It involves marking content with identifiers for unfinished tasks. Further information on this is available here.
Show in parallel
If you would rather see all the available content in parallel instead of reviewing just filtered publications, adding tag-bound styles to these elements will make them stand out from other content and from each other, In this case, such styles need not be used for delivering comprehensive manuals to customers. The only comprehensive manuals would be included as part of the review part of the workflow. Tag-bound styles would then be excluded from use with manuals that are delivered to users if there is no added value to them.
Designate incompleteness
If you use tags to locate incomplete sections marked with them, you can add means to highlight such sections when they are published in the style sheet. This lets you easily identify sections that are incomplete or uncorrected when you review the publication before it is delivered. Such an addition makes the review process both easier and more reliable in this respect.
Challenges
Since tags exist for purposes of filtering content and not to be used for styling, the latter application has its limitations and challenges. The most obvious such challenges are discussed below.
Forethought
Tags are used to filter content and style sheets do not let you define which rules apply in which situation. Users must thus understand in advance how these systems will interact and how tags are to be used when they have styles linked to them.
Using tags
When it comes to how you use tags, you must account for both which tags get used (together) and which elements they target. Since the same tags can be used on multiple types of elements and since different types of elements often require the use of specific rules for their layouts, it is especially important to know where to use the tags that are associated with rules on a style sheet.
In the case of note elements, for example, we usually recommend that you condition the main element itself. However, they let you add paragraph (p) elements inside them, and they can be conditioned in a variety of ways in place of the main element. When it comes to styles, it is important to decide on how they are to be applied and this entails that the tags associated with such rules must be used accordingly. One of the examples below shows an implementation where styling rules are connected to conditioned paragraphs inside note elements.
What matters is that tags are used consistently and in a way which is compatible with the value derived from associated styles. This may involve different tags having different methods of application. Such details ought to be recorded in your internal documentation on the proper use of DoX CMS.
Tag categories
The tag category determines the attribute associated with the tags in it. This makes the category in question a part of the selector for the style sheet when you apply layout rules to its tags. As such, if you change the category of the tag, you must also change all the parts of style sheets that reference it to match the tag’s new category.
This results in considerable added effort to when you make changes to the categories for tags if there are references to the tags in style sheets. Should you use tags in this way, you should thus ensure that their categories are suitable for long term use without any foreseeable changes to them.
Combinations
Since selectors for style sheets must be defined in a precise manner, you must also account for possible combinations of tags both within and between categories. Likewise, you must account for a style sheet’s limitations in terms of using tags together.
The problems involve defining which rules apply when different tags have their own rules and formulating the selectors for combinations of tags.
For a single rule such as element borders, the last applicable value in the style sheet applies between selectors that have the same level of priority. You should thus be careful when it comes to applying tags with associated rules in a style sheet from different categories to the same elements. If tags must be used together like this, one option is to use a different detail as the primary identifier of each tag category. For example, tags from one category might define the color of text or the background and those from another the color of an element’s borders.
Combinations of tags mostly require you to fomulate suitable selectors for all the intended combinations. This amount can easily become untenable to maintain which is why allowed combinations should be defined in advance. If you use different rules for different categories and each category has an internal hierarchy for which values take precedence, there will be fewer challenges related to combinations of tags. Linking styles to tags provides more value, when these combinations can be distinguished clearly, though. Otherwise, some tags are buried in such scenarios, and it is generally important to know that the designated elements also involve them.
Complexity
Styles linked to tags emphasize the complexity of making changes to style sheets. The reason is how tags are often used on multiple types of elements, each of which may require its own set of rules per tag. The sheer amount of tags also affects this as a system where different tags have their own styles requires styles for each tag in the included categories or at least for each of those categories.
As such, it can be a good idea to use a separate style sheet for the rules related to tags. When they are separated from other rules, they do not make it harder to make changes to primary styles since locating the correct parts is not hampered by the extra length.
Not all users might also know how to make changes to a style sheet. These kinds of more involved implementations require a level of expertise with CSS higher than the bare minimum. This is another reason why the implementation should be prepared in such a way that it accounts for various scenarios in advance. Doing so reduces later users’ need to study the implementation and to update it.
Limitations with rule use
CSS only allows one value for each rule to apply to a given element. The distinctions related to tags are done on top of other styling. As such, you must either reserve a set of rules for them when it comes to the affected elements, or you must provide tags with overriding values for said rules.
This is an issue when it comes to rules used for other standard solutions. For example, ::before pseudo elements are a great way to add tag-related identifiers to various kinds of elements. However, each element may only have one ::before pseudo element. They are usually used to add labels that tell whether a note element is a danger notifier or a warning, for example. This is why the example provided belore uses tags associated with ::before pseudo elements on the paragraphs (p) inside a note element. While each element may only have a single ::before pseudo element, this limitation does not extend to embedded elements. Each of them may still have its own pseudo element.
Example implementations
There are various concepts for and examples of the available implementations that include tags in style sheets.
References
References to tags involve the same syntax as those to other HTML attributes. Further information on the options involved is available here.
The exact format for references to tags in selectors is this:
[data-doxattribute-categoryID="tagID"]Replace ‘categoryID’ with the identifier for the tag that names said category.
Replace ‘tagID’ with the identifier for the tag in question.
Distinct styles
The option to use a separate style sheets for tag-related parts was mentioned above. This option enables more than simply easier management of style sheets. The contents of style sheets cannot be made conditional. As such, the closest approximation of this involves separate styles that include sets of style sheets related to different tags.
This allows there to be styles specifically for deliveries where only the missing parts have been designated like this instead of being filtered out, for example. You can thus show users the potential benefits of available upgrades. Especially digital deliveries allow you to also update the manual delivered during the upgrade to no longer include the same highlights.
Thus, you can add different styles for the different license levels of the same software, for example, and each of them would share the same default style sheet alongside different sets of tag-related style sheets. Each such delivery will include all the available content without filtering any of it out. Instead, a minimum delivery will include all the missing upgrades in such a way that their tag-bound styles will tell which packages include them. The styles for more advanced deliveries will include fewer such tag-related style sheets until the comprehensive delivery no longer needs any.
Missing images
When you use a tag that tells you that an image is missing on a fig element, these rules will show that the image is missing. Such a situation can involve the image still being prepared as the associated parts are written. If you forget to place the image, this is revealed during the review process. It is considerably easier to spot a mention of a missing image than that an image is missing.
Strictly speaking, this solution does not even require the use of tags. Tags make managing this easier, though, and it involves large changes to what is shown. Should users accidentally add several paragraphs (p) inside a fig element and not use the first one for the picture, the version not tied to tags would add a marker for a missing image.
Specifically, the selector checks the first paragraph (p) of a fig element which is marked in this way to see if it is empty. If that paragraph has no content, the style shows that an image is missing. This means that you must keep that first paragraph empty even when the fig element contains other content such as a table or a list.
.dita-fig[data-doxattribute-remainingwork="MissingImages"] p:first-of-type:empty {
display: block !important;
background-image: url("https://cdn-icons-png.flaticon.com/512/59/59836.png");
background-size: auto 100%;
background-repeat: no-repeat;
height: 50mm;
}Separation of notes
This example shows how the same note element has separate parts for a touch screen and a keyboard. Since this involves the use of ::before pseudo elements, the tags have been applied to the paragraphs (p) inside the note element. The note element itself requires its ::before pseudo element for its label.
This example also shows how you can link rules directly to tag categories. Doing this lets you avoid unnecessarily repeating the same rules for each tag in it. As the example shows, only the differences need to be specified for each of them. In this instance, that involves the content of the ::before pseudo element.
.dita-note p[data-doxattribute-options] {padding-left: 10mm;}
.dita-note p[data-doxattribute-options="Touchscreen"]::before {content: "👇";}
.dita-note p[data-doxattribute-options="Keyboard"]::before {content: "⌨";}
.dita-note p[data-doxattribute-options]::before {
position: absolute;
left: 20mm;
}Model-specific identifiers
This is an example of model-specific identifiers which identify the model in question with the help of borders in a colour associated with it and vertical text that shows the name of the model (W75). This expresses clearly where the borders of such a piece of content lie and to what model it is related. A characteristic color also makes immediate recognition easier when the user is browsing the manual because they need not process text content to locate such positions.
This implementation specifically applies to paragraphs (p). Other types of elements may require separate implementations.
p[data-doxattribute-device="W75"] {
border: 1mm solid lime;
border-radius: 3mm;
min-height: 4em;
}
p[data-doxattribute-device="W75"]::before {
content: "W75";
color: lime;
font-weight: bold;
font-size: 1.1em;
float: left;
writing-mode: vertical-rl;
text-orientation: upright;
margin: 0 4.5mm;
}Multiple tags
This solution is also applicable to contents that have several tags. This lets you specify all the models to which content that is not general is related. It is also an example of how the number of available combinations severely increases the amount of effort that is involved.
Including the names for each model as vertical text would be too space intensive. As such, they have been replaced with dots in each model’s associated color. These dots come from a single image file. In this instance, the colors for both models have also been included as borders with the help of sharply defined box shadows in each dimension in addition to borders proper. However, this solution can only accommodate two models at a time. If it is possible for the same content to have more than two tags that are used in this way, you must find other solutions such as border images that use a color gradient.
p[data-doxattribute-device="W66 W75"] {
border: 1mm solid lime;
border-radius: 3mm;
box-shadow: 0 0 0 1mm magenta;
min-height: 3em;
}
p[data-doxattribute-device="W66 W75"]::before {
content: "W66 W75";
content: "\00a0";
height: 10mm;
width: auto;
background-image: url("/Content/Images/twodots.svg");
background-size: auto 100%;
background-repeat: no-repeat;
color: lime;
font-weight: bold;
font-size: 1.1em;
float: left;
writing-mode: vertical-rl;
text-orientation: upright;
margin: 1mm 4.5mm;
}Summary
If you link styles to tags, you can fluidly distinguish parts that belong in specific deliveries in manuals and other documents. This lets you show the users other content as well if you want to make it available to them to motivate upgrades, for example. This way, the users will also identify these sections immediately. Even superficial browsing is enough for users to recognize them.
When tags have associated styles, it also makes the review process easier. They let the reviewer get a sense of all the content in an unfiltered document where the content to be filtered is differentiated in terms of style instead. If tags are also used to designate incomplete sections, you can also specify styles for them to highlight them during review. This makes it easier to recognize parts that might have been forgotten or parts that you already know need more work.
However, tags are not designed to be referenced in style sheets. This introduces its own challenges to possible implementations. The main challenge is the increase in the need to anticipate scenarios. Proper implementations require you to know in advance the types of elements on which tags will be applied and which tags can be used together on some of them. When you change the category of a tag, you also change its identifier for purposes of style sheets. As such, you must take steps to ensure that no such need will emerge. Otherwise, all the styles related to such tags must be updated each time when you change their categories.
Other challenges involve the complexity of the required implementations and the limitations of available rules. Each tag is generally used on multiple types of elements which can each require you to specify a separate set of rules in relation to the tag. Because this will generate a long list of rules, you should separate parts related to tags to be their own style sheet(s). This will also make it easier to assemble distinct styles with or without them. Rules being limited is related to how a given rule may only have one value per element. As such, you cannot reserve rules that are involved in the standard implementations for important types of elements for tags.