Can CSS or Eclipse read the parenthesized syntax described in the proposal?
From: Michael
Priestley [mailto:]
Sent: Tuesday, May 16, 2006 7:56
AM
To: Paul
Prescod
Cc: ;
Esrig, Bruce (Bruce); Robert D Anderson; Su-Laine Yeo
Subject: [SPAM] Re: [dita] Minutes
from Ditaval Meeting
Importance: Low
Re:
I personally felt that unless there is some engine that can
interpret these pass-throughs, there is no use putting the feature in the spec.
After all, output engines tend to evolve independently of the DITA
specification. If Michael knows that the Eclipse team is thinking about runtime
filtering then fine, leave it in. But if they still need to be convinced then
I'd rather the convincing happen before the specification does. After all, if
an output or display engine wanted to add that feature it could do so
independent of DITA.
Regardless
of Eclipse (which already supports
runtime filtering), CSS does. If the values are passed through to the HTML,
different CSSs can be applied to flag different things.
Michael
Priestley
IBM DITA Architect and Classification Schema PDT Lead
http://dita.xml.org/blog/25
"Paul
Prescod" <>
05/16/2006 08:35 AM
To
Michael Priestley/Toronto/IBM@IBMCA, "Su-Laine Yeo" <>,
"Robert D Anderson" <>, "Esrig,
Bruce \(Bruce\)" <>
cc
<>
Subject
[dita] Minutes from Ditaval Meeting
I
realized that I hadn't seen any email on the ditaval proposals. Then I realized
that that was because the email was sitting in my outbox. Sorry for the delay!
Also: I'm in transit and will not make the phone call today.
====================
Attendees
=========
Robert Anderson, IBM
Bruce Esrig, Lucent
Paul Prescod, XMetaL
Su-Laine Yeo, XMetaL
Discussion
==========
The specification should state that there can be
at most one occurrence of a "prop" element with no attribute
specified, at most one for each attribute with no value specified, and at most
one with each attribute value specification.
There is a section of the specification that
refers to the scoping syntax even though it has been removed. Search the spec
for the word "scoped".
The description of the passthrough attribute was
not obvious to all readers. In particular, it wasn't clear that passthrough
implies inclusion. This is also true of the flag attribute.
It would be helpful to have a motivating use case
for passthrough. Also, it would be helpful to know what it means in contexts
other than HTML output.
I personally felt that unless there is some engine
that can interpret these pass-throughs, there is no use putting the feature in
the spec. After all, output engines tend to evolve independently of the DITA
specification. If Michael knows that the Eclipse team is thinking about runtime
filtering then fine, leave it in. But if they still need to be convinced then
I'd rather the convincing happen before the specification does. After all, if an
output or display engine wanted to add that feature it could do so independent
of DITA.
There are places where the specification refers to
the action attribute as "action" rather than "@action".
This is inconsistent with other attributes.
There was some enthusiasm for the idea that
implementations issue a warning or informational
message in the case that an attribute or attribute value occurs in the content
but not in the DITAVAL. It seemed somewhat na鴳e to presume that the right
behaviour is just "include". If someone adds a parallel step to your
task that only applies to some context that is not relevant to you, then you
want it to GO AWAY by default, not be output by default.
We found it confusing that the alternative text
attributes occurred on different elements than the image references themselves.
We propose instead elements like start-image and end-image.
There was some enthusiasm for text-based prefixes
and postfixes as an alternative to images. We proposed "start-text"
and "end-text" as element names. One proposal was to collapse the
start-text-alt element and the start-text element by saying that the text be
used as alternative text if there was an image supplied or as prefix text if
there was not. Others found this confusing.
We should specify a way for images to be
conditionally flagged. For example, something along the lines of: "if a
background color is expressed for an image, it should be represented as a thick
border. If a foreground color is expressed, it should be represented as a thin
border."
We proposed to take out the list of colour names
in the specification. They could be included by reference as suggested by Paul
Grosso.
On the other hand, the link to the XSLT
specification implies that DITAVAL processors should support
the syntaxes defined here:
http://www.w3.org/TR/xsl/slice5.html#expr-color-functions
We should be explicit about what syntaxes we support. I personally would like to know whether XSL
will synchronize with SVG and CSS as defined here:
http://www.w3.org/TR/css3-color/#svg-color
Somehow we need a clear definition of what syntax
the attribute supports. It doesn't
matter much what the syntax is.
In the descriptions of @startimg and @endimg, we
felt that everything before the comma is redundant: "If flag has been set,
the image to use for flagging the beginning of flagged content." On the
other hand, it would be good to say whether it is an error to specify the
@startimg with @action=include, @action=exclude or @action=passthrough.
Printchar is a big open issue. There are three
models: HTML, FO and IBM-existing. Nobody knows whether HTML supports changebars. My proposal: keep princhar for
internal IBM use, but deprecate it. Add a coloured changebar feature that would
degrade gracefully to a background color in formats that do not support change bars.
If we add the start-text feature then the
">>" and "<<" characters described in the spec
could be DEFAULTS for revprop behaviour.
Proposal for Conflicts
======================
We proposed to handle style conflicts with a
singleton element called "styleconflict" that would allow ditaval
authors to say what happens in the case of a style conflict. It would have
foreground-conflict-color and a background-conflict-color attributes.
If two rules style the same element with a
different background colour, then fall back to the
styleconflict/@background-conflict-color.
If two rules style the same element with a
different foreground colour, then fall back to the styleconflict/@foreground-conflict-color.
If two rules style the same element with two
different types of underline, then use the
styleconflict/@foreground-conflict-color
Element called styleconflict, a foreground color,
background color and a style.
The defaults for these attributes are application
and media specific.
