ZedAI Styling Support

From zedwiki

Problem

The ZedAI profiles enable a limited form of CSS-like support through the Source Rendition feature's attributes. Although optional, they introduce the ability for producers to inline styles and run counter to best practices for document creation, namely the separation of content from style. Inlining styles leads to documents that are verbose, redundant and not easily updated.

The introduction of inlined styles was intended to facilitate the production of documents for formats unable to handle external styles, with discussion particularly focused on braille. The aim was to enable the production of valid documents for these formats, but it has become more clear that where special formatting options are needed they are better handled during transformation to those output formats.

Braille is a unique case, however, because it does not have an internationally recognized markup format to transform documents to. Much of braille production is regionalised, but some also piggybacks on other standards (like DTBook/ZedAI) to expedite translation. As a result, ZedAI documents are being looked to as translatable into a form that are still valid but also represent a new unique input into braille production software and processes.

This scenario represents a problem both from a practical and ideological perspective, as the master format has been "invaded" by an output format and handling both allows unwanted requirements to bubble up into the master documents. We should not be looking to exclude braille production, by any means, but the formatting options that exist now are perhaps better moved to a braille feature or profile so that ZedAI documents aren't formatted for a specific output but are again optimally designed to be transformable.

Adding to this problem is that the Source Rendition attributes only support a limited set of properties, are not easily extensible and are not intuitively applicable by producers (required order of properties, etc.).

Proposal

Move the profiles back to supporting the application of styles through class attribute names, through the following steps:

Revise the Source Rendition feature

The primary requirement is to remove the rend:rend attribute, which is the current quasi-CSS inline style element for print emphasis. As braille XML production is still largely in a nascent state, the needs and requirements are better left to the braille pipeline group to identify, codify and maintain as they evolve.

The second requirement is to remove the rend:indent attribute, which was added purely to identify non-indented first lines for braille (and is also better left for a braille group to determine how best to implement).

The rend:symbol attribute is currently only used for context breaks, so could be moved to an attribute specific to that element or dropped for a class. It does not introduce any specific CSS properties, so is also fine staying in the feature.

The rend:prefix attributes have some similarity to CSS (where they correlate with the list-style-type property), but were developed to handle formatting more complex than CSS alone allows. Removal would require re-assessing how we format lists and items and make formatting of notes complex. They should kept.

Encourage CSS as a fallback mechanism

We won't formalize in the specification that CSS stylesheets must be attached to documents, but through the Primer and FAQ examples we will encourage attaching them to assist in document exchange/processing. This approach will allow producers to use whatever internal processes they require to format outputs based on the class names, while providing a map to their styling in a universally understood format.

The Associating Style Sheets specification now supports media queries for targeting stylesheets/styles to outputs, so a document can include more than one map to its output requirements.

The ZedAI WG will not maintain a controlled list of class names, however. This kind of standardization is better done at the organization level where classes can be implemented as needed and without the additional hassle of ensuring they don't conflict with an external set.

Examples

The following examples are intended to show both why inlining CSS styles is a bad idea and why it's a good idea as an external mapping language.

Print Emphasis

With the current Source Rendition feature, a file could have all of its italicized markup tagged as follows to facilitate braille production:

<emph rend:rend="font-style: italic">…</emph>

Removing this attribute from the feature would encourage the use standardized class names without losing information and without the verbosity, as in the following example where the class value em replaces the inline style declaration:

<emph class="em">…</emph>

A processing agent or transformation process could then either have built-in logic to handle and format emph elements so marked or could read an attached CSS stylesheet to determine how the element was intended to be processed. The option is completely at the discretion of the producer.

To allow the interchange of documents between producers (and the acquisition of data from publishers), a means of providing the necessary information to resolve the class names is needed, which is where CSS makes more sense.

Attaching CSS stylesheets using the xml-stylesheet processing instruction would both allow for the creation of standardized organization-wide class names and provide a map and means for external producers and tools to also be able to manipulate the files. A default stylesheet could be appened as follows:

<?xml-stylesheet href="daisy.css" media="all"?>

which could indicate that wherever the em class name is encountered the source content should be rendered in italics:

.em { font-style: italic; }

An organization could then more easily control/change the styles that are applied to its documents, as styles could only be defined through the transformation processes and organization style sheets. External producers likewise could either adapt their processors to handle the file(s) using the stylesheet as a guide, or could plug them directly into CSS-aware tools for processing.

Colours

Using controlled class names can also simplify the inclusion of CSS information that can be rendered a number of different ways using different notations and shorthands, such as colour information. If inlined styles are used (which rend:rend currently has no way of handling, so the attribute/feature would have to be expanded for), a content tagger would have many different ways of expressing the same colour. Assuming rend:rend would have to be migrated to a proper CSS style attribute, all of the following would mean the same thing:

<emph style="color: red;">…</emph>
<emph style="color: #ff0000;">…</emph>
<emph style="color: #f00;">…</emph>
<emph style="color: rgb(255,0,0);">…</emph>
<emph style="color: rgb(100%,0%,0%);">…</emph>

The use of class names, however, would mean that staff would only ever have to know to tag the colour by name:

<emph class="red">…</emph>

The list of colour names could be limited to the X11 colours (which browsers support), or custom names could be created as necessary (which would not be possible in pure CSS).

Excluded characters

Another common processing scenario is the automatic inclusion of character data per output format. A typical example is the inclusion of quotation marks around dialogue. Rendering the quote characters from the source document is not always what is wanted. Braille producers will often flip single quote characters to double quotes when they are used as the predominant quote character (to remove the extra cell that single quotes output). All double quotes are likewise flipped to single quotes when this happens.

To accommodate this kind of re-processing, all dialogue is marked with d tags and the actual quote characters are dropped from the source document, leaving it to their output transformation process to insert the correct characters.

<p><d>…<d>, she said. <d>…</d>.</p>

Although a convenient means of handling this requirement, it conveys none of the information from the source. A class name solution would be verbose, as every d tag would have to carry information about its quote type as follows:

<p><d class="doubleQuote">…<d>, she said. <d class="doubleQuote">…</d>.</p>

There are a number of ways that a producer could hint at the default quoting (e.g., metadata or identifying only variations from a default character), but a CSS stylesheet attached as a map is again a simple, easily understood way to convey the formalize this information in looking beyond the scope of what any one producer does internally with their files. For example, to indicate single quotes were in the source document, a producer could attach a default stylesheet with the following declaration:

d:before, d:after {
   content: "'";
}

Using media queries, another stylesheets could be appended so that the quoting style used for braille output could also be identified:

<?xml-stylesheet href="default.css" media="all not braille"?>
<?xml-stylesheet href="braille.css" media="braille"?>