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
----- Original Message -----
From:
Wright,
Barton
To: Nicolas RAINARD ;
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
<dl
class="glossary">
<dt
id="term01">
Definition term 1
</dt>
<dd>
Definition data 1
</dd>
<dt
id="term02">
Definition term 2
</dt>
<dd>
Definition data 2
</dd>
</dl>
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
<ol
class="qandaset">
<li
id="qandaentry01">
<p
class="question">
FAQ question
1
</p>
<p class="answer">
FAQ answer
1
</p>
</li>
<li
id="qandaentry02">
<p
class="question">
FAQ question
2
</p>
<p class="answer">
FAQ answer
2
</p>
</li>
</ol>
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 <ul>
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: For
additional commands, e-mail:
