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:
<div class="titlepage"><div><div><h1 class="title"><a
id="d0e45"/>Preface</h1></div></div></div>
Into this:
<div class="titlepage"><h1 class="title"><a
id="d0e45"/>Preface</h1></div>
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 <div class="foo bar"> (assuming there were no conflicting
attrs that couldn't be combined).
I guess the places where tables are used are easily found. Here are the
ones I see just looking around:
variablelist (when list presentation is set to table...since this is an
option already I guess the desire would be for a css-based tabular
layout).
calloutlist (when callout.list.table is 1. The alternative now is <dl>,
but those don't work well with callout graphics apparently)
qandaset
simplelist
blockquote
The headers and footers in chunked output
funcprototype
The viewport in process.image
graphical admonitions
David
________________________________
From: Bob Stayton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 15, 2007 10:48 AM
To: Wright, Barton; Nicolas RAINARD;
docbook-apps@lists.oasis-open.org
Subject: Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob
Stayton, Jirka Kosek - About a former XHTML accessiblity project
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
[EMAIL PROTECTED]
----- Original Message -----
From: Wright, Barton <mailto:[EMAIL PROTECTED]>
To: Nicolas RAINARD <mailto:[EMAIL PROTECTED]> ;
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
<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: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
