RE: [dita] outputclass on map elements

From
Grosso, Paul <>
Date
2006-06-07T14:26:09+00:00
ID
Thread
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:] 
  
Sent: Tuesday, 2006 June 06 17:01
To: 
  
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