OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] Docbook website XSL question

In my own Website customization, I found it necessary to add support for 
CSS classes and id attributes. I may been going about it wrong 
(corrections welcome), but FWIW:

It looks like the docbook.xsl strategy is to apply the appropriate XML 
element name to the class attribute, in this form:

<xsl:template match="abstract">
   <div class="{name(.)}">

This example generates the HTML code <div class="abstract">,
allowing the CSS author to write rules for the div.abstract selector.

The problem is, sometimes the resulting classes are not granular enough 
for effective CSS formatting. For example:

<div class="section">

applies to nearly all the content in my pages. I wanted to provide more 
descriptive classes at this level than the XML element name. For 
example, <div class="albums"> and <div class="production"> allows my CSS 
to format div.albums differently from div.production. The other 
limitation of this model is that CSS class names are limited to the 
names of elements. I tried to use the role attribute to work around 
these problems, but found that I could generate classes only for a small 
group of elements (controlled by 'use.role' params).

So much of my customization was to add role support to a bunch of 
templates, and that's my first suggestion: more support for HTML classes 
based on the role attribute. This provides more granularity, and makes 
the available class names extensible without modifying the xsl.

The second CSS problem I had was using XML ids. They seem to generate <a 
name> anchors, but not id attributes as far as I can tell. For example:
   <para id="test"> generates
   <p><a name="test">, not
   <p id="test"> , which would be useful for CSS.

I recognize that ids have other purposes in XML than in HTML, so I'm not 
sure how they should be mapped. I simply note that ids seem to be 
unavailable for the CSS designer.

The last point I would make is more of a question: I wonder if full CSS 
support may be beyond the reasonable scope of docbook.xsl. For example, 
I don't know how you would support using any attribute as a selector, as 
CSS2 allows:


It might be useful to understand how far docbook.xsl can and can't take 
us with CSS.

Bob Stayton wrote:
> I'm not sure I understand the question.  The current website stylesheets
> make use of the DocBook XSL templates, and they output class attributes in
> the HTML.  Those class attributes are suitable for use with CSS.  Is the
> question whether such class attributes exist, or whether there should be
> more of them?
> Bob Stayton
> Sagehill Enterprises
> DocBook Consulting
> bobs@sagehill.net
> ----- Original Message ----- 
> From: "Marcin Zalewski" <zalewm@rpi.edu>
> To: <docbook-apps@lists.oasis-open.org>
> Sent: Friday, July 23, 2004 8:01 AM
> Subject: [docbook-apps] Docbook website XSL question
>>I am trying to generate my webpage using website XSL. After lots of
>>trials I finally got it to work and produce valid XHTML.
>>However, there are only two ways to produce a webpage using the default
>>distribution: text only or tabular. I do not want to use tables for the
>>layout of my page and I want to control all the styling through css. I
>>wrote an ugly customization css that produces html free of any styling
>>I was wandering if there is a stylesheet available somewhere that
>>produces a css-ready layout. What I would expect is an html document
>>where all elements are named (through class or id) and layered for easy
>>style with css.
>>Does anyone know of an existing stylesheet that does what I need?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]