ZedAI CSS Support

From zedwiki

Jump to: navigation, search

Contents

Background

While detailed semantic markup is essential to being able to use and re-purpose data effectively, without any associated means of attaching styling information even the best markup gets rendered averagely and/or suffers from cookie-cutter output.

Early on in the development of the ZedAI specification it was decided that hooks would be incorporated to allow use of the Cascading Style Sheets (CSS) specification for handling the application of styles. It was also early on in development that concerns were raised about the ability to use ZAI documents with processing software that was not completely XML aware and that may have limited ability to process class names or inline styles.

These discussions gave birth to the Content Rendition feature as a means of allowing some styling information to be injected directly into documents in as unobtrusive a fashion as possible, while maintaining document validity. The subsequent years have highlighted a number of holes in this approach, namely that it mistakenly requires ZAI documents to also be direct inputs into other processes (instead of transformable into), it is impossible to predict all of the styling that producers will require (in non-CSS/stylesheet contexts) and that the various decisions made by producers working in various environments will impact on the ability to create any semblance of a common tool set or processing predictability.

It is also understood that the decision of what to support and how will have a significant impact on the adoption of the standard, but a balance needs to be struck between what should be expected in the core and how far it can and should be influenced by potential output requirements (and whether there are better ways to accommodate both needs).

Overview

Advantages

Although lacking the power of more complex typesetting languages and stylesheets, CSS has the advantage of being easy to learn, having widespread support in all browser-based rendering formats and providing a wide range of commonly-used styling attributes and functionality.

All previous versions of the DAISY standard have also enabled support for CSS styling because of the common root the text portion of the standard shares in XHTML, making CSS a natural fit both looking ahead to new iterations of the HTML specification (and EPUB) and for backwards compatibility with previous versions of the DAISY standard. It also makes the migration path to the new standard for existing producers that much simpler, as it removes the requirement to learn/implement a new styling language.

CSS also provides a simple, clean and relatively unobtrusive method for adding style information, at least in its class attribute form where style information is kept separate from the document content.

Disadvantages

One of the primary disadvantages of CSS is the inability to precisely target styles without a certain measure of verbosity in files (i.e., the lack of selectors, such as XSLT+XPath provides). It is also primarily targeted to reflowable layouts. Level 3 of the specification is beginning to address some of these problems, but it is a many-headed specification and few pieces, if any, that are the most useful in the ZAI context are soon going to be formal recommendations.

A dearth of parsers outside of the web context further complicates adoption of CSS. While there is plenty of documentation advocating CSS for XML, in practice CSS more typically gets applied as part of transforming XML into (X)HTML instead of for actual rendering of XML outside browser contexts. The difficulty of transferring CSS information directly into how a transformation chain practically processes elements for rendering in a print medium, for example, should not be underestimated.

In addition, the cascading nature of the styles (both by class and through inline styles) coupled with inherent traits and shorthands makes building an internal representation of the styling for an element more complicated than the simple tokenizing of the style blocks that make up a stylesheet.

The lack of tool support in accessible publishing for XML and CSS compounds this problem, particularly as relates to braille production. Although some tools have good support for XML, support for attributes is further behind, and those that can handle both often cannot treat attribute values as more than simple text strings (i.e., lack the ability to tokenize class names and properties and separately resolve/handle them).

The various levels of the CSS specification add additional overhead to the problem. The goal should not be to limit producers from using the newer and more advanced CSS properties, but the greater range of support allowed the more complicated it will make the proper processing of documents.

Integration

The use of CSS is not a requirement for ZAI document creation, nor is the support for it by processing agents. In theory, any stylesheet or typesetting format could be used with ZAI documents, and the specification remains flexible to future directions to ensure that it remains relevant.

Practically, however, the inclusion of the class attribute and the recommendation of the Associating Style Sheets specification for attaching stylesheet is intended to promote the most prevalent option currently available, namely CSS.

Recent developments

Since the inception of the ZAI work, the syntax for parsing CSS style attributes has been formalized and reached Candidate Recommendation status (http://www.w3.org/TR/2010/CR-css-style-attr-20101012/).

Although this specification does not require a specific style attribute for the information, it removes any ambiguity in how ZAI processors would have to handle the information contained in one.

ZedAI Support

The use for CSS in the profile catalogs has never been in serious question. What haven't been fully addressed are the following:

  • whether it should be formally recognized/supported;
  • whether support should be limited to the role attribute and attaching stylesheets, or whether a proper inline style attribute is needed;
  • if an inline attribute is added, what that does to optionality of CSS;
  • whether the faux-CSS functionality is a necessary feature;
  • how we expect to deal with changing style requirements moving forward if it is;
  • whether the the CSS style attribute could/should replace much/all of the Content Rendition feature; and
  • whether the level of support should be addressed;

Two primary cases have evolved from the working group discussions that have brought these issue back to the forefront:

  1. fuller support for print emphasis and styling, specifically as relates to braille; and
  2. support for the automatic inclusion of non-essential character data.

The first issue is what led to the creation of the rend:rend attribute and started work on the Content Rendition feature. The original idea was that the attribute would provide a limited set of CSS-like values that could be attached for use in non-CSS aware environments. Three CSS property/value pairs were specifically identified as being useful for reproducing print emphasis in a braille context: 

font-style: italic;
font-weight: bold;
text-decoration: underline;

Although never intended as a comprehensive set, it didn't take long before additional shortcomings had to be addressed. A rend:indent attribute was added to address the problem of varying indentation on paragraphs and rend:prefix followed for inserting character data before items, entries and notes. It has also become evident that colour variations are going to need some mechanism for support, as part of the Unified English Braille code (UEB), as well as additional print emphasis types like strikethroughs. Adding new style values for rend:rend is complicated by its controlled nature, however. The order each property can appear in is fixed, so new permutations of all possible arrangements have to be created whenever the list is added to.

The initial idea that a ZAI document would be a direct import into a braille processor may need to be reviewed, as well. The Content Rendition feature was a means of allowing external styling information that braille processors cannot handle to be brought back into the document while still remaining valid. While clearly a legitimate need, whether including as a feature for composing ZAI documents was the best method to achieve this requirement is not so clear.

The specification has since become more focused in terms of its role as a master source for facilitating multiple outputs, and work has begun on developing a braille transformation process for the Pipeline and on an associated set of markup requirements. In this new model, and where support for non-CSS handling has been identified as a braille-specific need in most cases, it may make more sense now to move these attributes into a braille feature (where the requirements and rules can be maintained by the people who require them).

Clearly separating the contexts (CSS in the core and non-CSS relegated to a post-transformation configuration) would additionally have the benefit of making document processing predictable. If the door open is left open to multiple ways of achieving the same effect, then anyone sharing documents or processing them is going to have to be able to handle both methods. This problem already exists, however, in the sense that any stylesheet can be attached (even if the options are limited).

Compounding the support problem is the ambiguity surrounding what styles will be needed by producers as they adopt the standard now and in the future. The most probable scenario is that the Content Rendition feature will be under perennial review, but there is at least a remote possibility that a lack of immediate support for needed processing informationwould drive braille producers to create their own profiles with their own solutions to the styling problem and fracture the ability to easily share documents.

The application of styling information is the more straightforward issue that needs resolution. Tied to it, and complicating it, however, is the need for specialized styling functionality, like injecting character data. One particular example that remains an open issue for the working group is how to render quote characters around dialogue and quoted text. Hard-coding the characters into a document limits its usability, especially for formats like braille where some codes and jurisdictions will flip the characters to reduce cell counts.

Including the quoting information in metadata or as part of a transform is a possibility, but translates into cookie-cutter output and often results in cases where the quoting no longer matches the intent of the source document. Using Unicode opening and closing characters is another possibility, but as the characters are not part of the standard keyboard their input can be a cumbersome process.

A similar issue is automatically inserting separator characters between elements, the typical example being terms and definitions. Again, in a cookie-cutter world outputting the same characters in every instance renders a document that no longer can be assured to be faithful to the author's intent.

The CSS :before and :after pseudo elements represent an elegant solution to this problem, both for setting up default handling and for singling out niche cases that would get lost by the application of global rules. Advocating their use, however, might push the working group into more definitively supporting CSS, which in turn would affect any tools built to process the files.

Devising a solution that completely avoids CSS and provides this same expressiveness is going to be cumbersome and in the end will result in the same functionality having to be built into a transformation chain.

Issues

Support requirement

Should we formally endorse CSS support? Our inheritance of the class module together with the use of the Association of Style Sheets specification for identifying attached stylesheets implies support, but it is not explicitly stated anywhere (and the door is left open to using other methods).

And although the Z39.86-AI specification defines the way in which compliant XML grammars must be built, it is not fundamentally about how transformable documents must be. If we become more explicit about CSS support, what are we saying about processing agents:

  • they are required to be able to render/transform documents based on attached CSS stylesheets because we have core support, but all other stylesheet types are optional;
  • they should be able to CSS, but there is no expectation of support;
  • support for CSS or any other stylesheet type remains optional and tools only support what they want to support.

The Content Rendition feature allows the inline methods for specifying CSS-like properties to be optionally ignored by PAs by its nature, so is immune from this issue.

Support methods

Is it necessary to support the complexity of both class and style attributes in the core? Would any of the following options be better:

  • replace rend:rend with rend:style and keep it an optional feature;
  • not include a style attribute in the core/features but propose its use for output formats that cannot support class attribute resolving (e.g., a brl:style attribute for applications that need the information inline);
  • not include a style attribute and encourage the cascading of class names where information is needed inline (e.g., class="bold italic underline");
  • move all CSS support out of the core and into a feature and not directly accommodate either CSS or non-CSS implementations.

Support level

What level of CSS support do processors have to provide? Even if we provide a means of inlining styles in a non-CSS format, we still support CSS styling through the class attribute and it remains an integral part of the specification. Level 1 is assumed, and level 2 is necessary for specifying media types, but what aspects of level 3 would be useful (if at all) has not been fully investigated.

Transform support

CSS is currently only useful where the applied styles can filter directly through into the output format. No tools are known to exist that can take an XML file and a CSS stylesheet and render a non-browser based output, certainly none for accessible production.

Standalone CSS parsers are not that difficult to find, some of which follow:

While the above applications all appear to be capable of reading a stylesheet and creating a representation of it, the problem still exists of how to take that information and use it in the correct context and in the correct way while processing an XML document.

It is not clear how the information could be used in conjunction with an XSLT transform alone, which means custom parsers would need to be built to read an XML document and determine the context of each element, query the CSS representation to determine the style(s) in use and then apply the proper output formatting.

Retrieved from "http://www.daisy.org/zw/ZedAI_CSS_Support"
Personal tools