I agree with both Paul and France. I think
the clincher is that most writers should not be aware of the CSS definitions,
because otherwise you end with all the nasty problems we are trying to solve
with XML. This is one case where practical application trumps backward
compatibility.
From: France Baril
[mailto:France.Baril@ixiasoft.com]
Sent: Tuesday, June 13, 2006 8:53
AM
To: dita@lists.oasis-open.org
Cc: Erik Hennum; Grosso, Paul
Subject: RE: [dita] outputclass on
map elements
I'm with Paul on this, it makes me very
nervous too, but not because it's HTML only.
My reason is that having CSS
information in the content means that you can never redesign the HTML
style completely or use CSS that don't have that class
defined. I wonder if the proposal should not be to remove this attribute from
topics instead of adding it to maps.
I'm aware this could cause issues with
backward compatibity, but it could prevent other issues for users down the
road.
Moreover, shouldn't most writers be
completely ignorant of the CSS definitions?
France
Baril
Documentation
Architect/Architecte documentaire
IXIASOFT
tel.:
+ 1 514 279-4942 (new extension number 350)
+ 1 877 279-IXIA (new extension number 350)
fax:
+ 1 514 279-3947
france.baril@ixiasoft.com
[ www.ixiasoft.com
]
Let's Talk XML
From: Erik
Hennum [mailto:ehennum@us.ibm.com]
Sent: June 7, 2006 1:57 PM
To: Grosso, Paul
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] outputclass on
map elements
Hi, Paul:
To clarify, the outputclass attribute is available on the topic elements in
DITA 1.0. The attribute should have been provided on the DITA map elements as
well -- hence the bug fix.
The outputclass attribute really fills a role similar to the DocBook role
attribute. Where the output format has a concept of class or role (as with
HTML), the outputclass can be copied into the output, but its primary purpose
is to provide informal semantic extension rather than stuff names into the HTML
class attribute.
The attribute could have a better name.
Erik Hennum
ehennum@us.ibm.com
"Grosso,
Paul" <pgrosso@ptc.com>
"Grosso,
Paul" <pgrosso@ptc.com>
06/07/2006 07:24 AM
|
To
|
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [dita]
outputclass on map elements
|
|
It makes me nervous to embed HTML-only stuff in the DITA model.
How do
you propose to treat this attribute for print/pdf output? How do you propose to
write up this attribute in the spec in an output-independent fashion that still
remains useful?
paul
From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, 2006 June 06 17:01
To: dita@lists.oasis-open.org
Subject: [dita] outputclass on map elements
Hi,
Esteemed Technical Committee:
The 1.1 bug list (http://wiki.oasis-open.org/dita/Bug_fixes_for_DITA_1%2e1#preview) has an item that never received final
disposition -- adding the outputclass attribute to the map elements (<map>,
<topicref>, <navref>, <anchor>, and <reltable>):
http://lists.oasis-open.org/archives/dita/200602/msg00082.html
To recap, the outputclass attribute assigns an informal role to an element. As
such, outputclass is quite useful for extending the semantic without formal
specialization. For instance, you can use outputclass to mock up a
specialization in the base document type or to create handles for custom
processing. Typical output processing for HTML copies the outputclass into the
class attribute so users can create custom CSS styling.
Currently, outputclass is only available on topic elements and not on map
elements. As a result, you can't easily mock up a map specialization or provide
handles for custom map processing.
The main implication of map outputclass for the base output processing would
seem to be to collect the outputclass values for the topicref and provide them
on the outermost wrapper of the HTML content for the topic. The latter
enhancement would let users style a topic in CSS based on the role played by a
topic within a map.
The outputclass attribute is close to being a universal attribute -- it applies
to a similarly large list of elements and merits similar treatment. I'd like to
request that we finalize this bug fix at the next meeting.
Thanks,
Erik Hennum
ehennum@us.ibm.com