I've long wanted to make DocBook's XHTML cleaner, and I've started on it more than once. But my approach was too big, looking at the entire XHTML design, and so each time it was put off due to lack of time.

As people have pointed out, perhaps only a few elements need to be changed. We could have a parameter (xhtml.clean?), and add xsl:choose statements to some element templates to produce alternate output if that parameter is set. What would really help me is a list of elements that need this treatment.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net


----- Original Message -----
From: Wright, Barton
To: Nicolas RAINARD ; docbook-apps@lists.oasis-open.org
Sent: Tuesday, May 15, 2007 6:16 AM
Subject: RE: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project


Nicolas,

You state the case very well. I have also longed for a simple, modern, elegant XHTML output from DocBook source. This goal was elusive when designing Iona's DocBook-sourced XHTML books, and we fell far short of the clean output over in the Linux from Scratch project.

It is sometimes disappointing to have set up a modern document building process, where books can be generated with the flick of the wrist -- only to see the output littered with dozens of empty div's and table-based layout. DocBook-generated HTML is easy to spot in view-source mode because of these features, and DocBook-generated XHTML rarely passes standard validation tests. Sometimes it looks like a great leap forward into the 1990's.

But even so, DocBook is the only game in town. And you don't have to buy an entire ecosystem like with most adventures in the DITA world. Perhaps over time, we can slowly steer the great DocBook tanker into the safe harbor of validated XHTML output.



------------------------------------------------------------------------------

<snip>

My goal is not only accessibility (I think these results are tolerably well accessible). What should be a common goal is to get a semantically correct, and elegant, output.

For example, tables should be used only to present tabular data and not for the layout (but it seems everybody agrees with that).

Definition lists should be used to present... lists of definitions.

Here is an equivalence:

DocBook

<glossdiv>
<glossentry>
<glossterm>
Definition term 1
</glossterm>
<glossdef>
Definition data 1
</glossdef>
</glossentry>
<glossentry>
<glossterm>
Definition term 2
</glossterm>
<glossdef>
Definition data 2
</glossdef>
</glossentry>
</glossdiv>


could be transformed to:


XHTML

Definition term 1

Definition data 1

Definition term 2

Definition data 2

DocBook

<qandaset>
<qandaentry>
<question>
FAQ question 1
</question>
<answer>
FAQ answer 1
</answer>
</qandaentry>
<qandaentry>
<question>
FAQ question 2
</question>
<answer>
FAQ answer 2
</answer>
</qandaentry>
</qandaset>


could be transformed to:


XHTML

1. 
   

   
   FAQ question 1
   

   
   

   
   FAQ answer 1
   

   
   


2. 
   

   
   FAQ question 2
   

   
   

   
   FAQ answer 2
   

   
   

As you can see, there is no more need for tables, as well as hard-coded sections numbers, since they are automatically generated by the browser (and it is possible to use a

instead if we don't want automatic numbering).

Of course, DocBook is much more detailed, but it is considerably easier to strip some details than the reverse. Both DocBook and XHTML are XML flavors and they share many semantical structures, so it should be fairly easy to better preserve these structures. What are markups in DocBook can be transformed as attributes in XHTML to preserve the semantical meaning and give the required hooks for CSS presentation. In fact, it is much easier than transforming to "old-fashioned" HTML with tables layout.

I'll have a look at the LFS XHTML XSLT (proposed by M. Canales), and see if they comply with such a state of mind.
--------------------------------------------------------------------- To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

El Martes, 15 de Mayo de 2007 17:47, Bob Stayton escribió:
> I've long wanted to make DocBook's XHTML cleaner, and I've started on it
> more than once. But my approach was too big, looking at the entire XHTML
> design, and so each time it was put off due to lack of time.
>
> As people have pointed out, perhaps only a few elements need to be changed.
> We could have a parameter (xhtml.clean?), and add xsl:choose statements to
> some element templates to produce alternate output if that parameter is
> set. What would really help me is a list of elements that need this
> treatment.


IMHO, the first step would be to create a set of XHTML pages containing how
each DB element, and its attributes, should be mapped into XHTML-1.1 +
Ascessibility (valid XHTML-1.1 could be served as valid XHTML-1.0 if needed
for browsers compatibility).

Having that example mapping to know the actual changes needed, can be
evaluated if that xhtml.clean parameter could be used, if the current xhtml/
templates could be full-changed to generate the new code, or if will be
better to have two separate xhtml templates sets: the current one plus a new
xhtml1.1 tree.




--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info
TLDP-ES: http://es.tldp.org

Regarding the empty divs, what about a post-processing step (like one
pass profiling, but on the other end) that processes the output and
turns this:



Into this:



If you had a div with a class that had a child div with a class and the
child div didn't have any following siblings, you could even combine the
classes, to