RE: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project

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:] 
  
Sent: Tuesday, May 15, 2007 10:48 AM
To: Wright, Barton; 
  Nicolas RAINARD; 
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


  
 

  
 

  
    
----- 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: