OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] DITA Issue Proposal: Styling Options for Conditional Text

Erik, would your proposal to merge the requirements result in changes to the ditaval format? Also, are you suggesting that the styling options proposal could be used to exclude text from output? While I can see the architectural aesthetic of having a single format to control all presentation capabilities, I'd be reluctant to in any way increase the complexity of the ditaval format, beyond the simple styles described in Paul's note below.

Michael Priestley

Erik Hennum <ehennum@us.ibm.com>

08/31/2005 09:36 AM

"JoAnn Hackos" <joann.hackos@comtech-serv.com>
dita@lists.oasis-open.org, "Paul Prescod" <paul.prescod@blastradius.com>
RE: [dita] DITA Issue Proposal: Styling Options for Conditional Text

Hi, JoAnn and Paul:

We might want to include this issue in the existing item, 39 Policy-based style mechanism.

(By the way, JoAnn, I'm an interested party on that item.)

I'd suggest that our approach to style policies should consist of selectors and properties. In essence, a policy file should be able to attach any style or layout property (including an exclude or hide property) to any content fragment.

The selectors should be CSS-like matches on inherited class, instance identifier, token value, or nesting of the above. The goal should be to put policy decisions in the hands of the broad audience that wouldn't be successful with XSLT. (Because XSLT is always available as a general fallback, style policies can provide a purely declarative set of selectors and properties rather than executable flow and expressions.)

To produce books from bookmaps, the set of properties will need properties like page break and so on.

A bit more on the thought:


Paul's note below highlights the convergence of this approach with DITA conditional values, which also provide a system of selectors and properties. In a perfect world, existing DITA values files would remain valid instances of the more general style policies format. A transform might be acceptable.


Erik Hennum

Inactive hide details for "JoAnn Hackos" <joann.hackos@comtech-serv.com>"JoAnn Hackos" <joann.hackos@comtech-serv.com>

"JoAnn Hackos" <joann.hackos@comtech-serv.com>

08/29/2005 07:55 AM


"Paul Prescod" <paul.prescod@blastradius.com>, <dita@lists.oasis-open.org>



RE: [dita] DITA Issue Proposal: Styling Options for Conditional Text

I fully support this proposal.


JoAnn T. Hackos, PhD

Comtech Services, Inc.

710 Kipling Street, Suite 400

Denver, CO 80215




From: Paul Prescod [mailto:paul.prescod@blastradius.com]
Monday, August 29, 2005 1:04 AM
[dita] DITA Issue Proposal: Styling Options for Conditional Text

We propose that the DITAVAL file be standardized for interchange among applications.

The DITAVAL file currently provides 16 colors for styling conditional elements. We propose that the styling options be extended for scalability, to support multiple output devices, and to incorporate current knowledge of human factors.

Feedback from our customers indicates that it is important to be able to signal conditions without relying on color. Non-color formatting is important in monochrome printouts and for color-blind users.

We propose allowing users to assign the following formats to conditions: underline, double underline, italics, overline, and bold.

We propose allowing users to set background colors for conditional text. For the vast majority of users who work in black text on a white background, light highlight colors provide good contrast for legibility.

Paul Prescod and Su-Laine Yeo
Blast Radius XMetaL

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]