Some recent discussion on this list made me think a bit more about our
concepts with regard to the use of class attributes ...
I'd appreciate your comments.
Ferdinand Soethe
Function of class-Attributes
----------------------------
Forrest components (and users) use "class"-attributes in 4 different
ways:
1. Forrest uses class-attributes to preserve special meanings when
transforming custom grammer (such as xdocs) to html.
Example: In the following clipping (from document2html.xsl) you can
see that the xdocs-elements 'warning', 'note' and 'fixme'
(that have no equivalent in html) are transformed to
div-elements and assigned a class-attribute to preserve
meaning and allow for special formatting treatment.
<xsl:template match="note | warning | fixme">
<xsl:apply-templates select="@id"/>
<div>
<xsl:call-template name="add.class">
<xsl:with-param name="class"><xsl:value-of
select="local-name()"/></xsl:with-param>
</xsl:call-template>
2. Skinning uses class-attributes to identify, format and place skin specific
(often generated) components such as menus and tabs.
3. Users add class-attributes to elements to create new meanings or
add 'submeanings' to existing elements and facilitate formatting of
those with the Extra-CSS-mechnism.
Example: By adding a class 'instructions' to a simple bulleted list
I can format these lists differently with extra-css.
4. Plugins (often) need to use class-attributes (just like Forrest in
2) to carry meaning over to html.
(My) Problems with the Current Approach
---------------------------------------
In customizing Forrest and attempting a plugin I found that our
current system will generally take care of functions 1 and 2, supports
3 to a limited extend and has few or no provisions for handling
funtion 4.
The problem I have identified so far are:
1. Class-transparency
Most of our transformations are not class-transparent. A
class-attribute fed into that transformation is often ignored,
or overwritten.
2. No Conflict-Handling
There is not concept to avoid or handle conflicts, when more than one
function tries to add class to an element.
3. No rules for indirect transport of classes
For example: Even though xdoc has a body-element, attaching a class
or id to it will not carry it over into the body
element of the final html because there is no direct
tranformation.
Avoiding these problems
-----------------------
Since we are in the process of reqriting most of our pipelines for the
transition to xhtml, I'd like us to discuss a couple of binding rules
for the handling of class in Forrest.
Some of these could be (please add and correct)
- all transformations (including those in skinning and plugins)
must preserve foreign class attributes. That is: Any class attributes
attached to an element going into the transformation must be carried
over into the resulting element.
Transformations that significantly change the structure of elements
or create multiple elements in the result tree (see the example of 'warning')
should try to preserve class-attributes true to their meaning. For
example transfer the warning-class to the surrounding div-element
rather than its child element.
Exception: Class-attributes created as internal markers within a
chain of transformations may or even must be removed.
- When adding classes to elements that already have a class attribute,
each new class it added to a space separated list. All
transformations and css-formatting must be written to properly handle such
class-lists.
- To avoid conflicts between class names created by different modules,
a module-specific prefix is added to the class name. For Forrest core
modules and extra-css-classes this prefix can be static while each new
plugin should be automatically assigned a unique prefix to use with
all their class names.
Example Class Naming
function prefix
Forrest core fo..
menus fomu-
tabs fota-
body fobo-
footer fofo-
etc.
extra-css ecss-
plugin pi..
skills-plugin piskill-
docbook-plugin pidb-
etc.
- Facilitate indirect transport
To facilitate indirect transport (such as the class from body of
xdocs to body of html) we should create and clearly document
class-channels in our transformation. In other words, make sure that
there is a channel class or id attributes into all major elements of
a page and document it ("if you want id in the html-body, attach it
to xdocs document-element").
Open Issues
-----------
I have no idea how all this will be effected by structurer. Can one of
the insiders please comment.
--
Ferdinand Soethe
