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
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: Erik Hennum <ehennum@us.ibm.com>
- Date: Wed, 31 Aug 2005 11:07:09 -0400
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
mpriestl@ca.ibm.com
Erik Hennum <ehennum@us.ibm.com>
08/31/2005 09:36 AM
|
To
| "JoAnn Hackos"
<joann.hackos@comtech-serv.com>
|
cc
| dita@lists.oasis-open.org,
"Paul Prescod" <paul.prescod@blastradius.com>
|
Subject
| 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:
http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200409/msg00022.html
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.
Thanks,
Erik Hennum
ehennum@us.ibm.com
"JoAnn
Hackos" <joann.hackos@comtech-serv.com>
"JoAnn Hackos" <joann.hackos@comtech-serv.com>
08/29/2005 07:55 AM
|
|
I fully support this proposal.
JoAnn
JoAnn T. Hackos, PhD
President
Comtech Services, Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
303-232-7586
joann.hackos@comtech-serv.com
http://www.comtech-serv.com
From: Paul Prescod [mailto:paul.prescod@blastradius.com]
Sent: Monday, August 29, 2005 1:04 AM
To: dita@lists.oasis-open.org
Subject: [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]