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] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project


No-one is taking anything away from anyone, except perhaps the notion that Netscape 4.7 is the yardstick for interoperability.

XHTML has already become the lingua franca for compiling representations of documents from a variety of sources for further processing.

Quite often, the output from the DocBook XSLT stylesheets becomes input for another process. And yes, tables and weird spans and divs are a PITA.

Kind regards
Peter Ring

> -----Original Message-----
> From: chris.chiasson@gmail.com [mailto:chris.chiasson@gmail.com]On
> Behalf Of Chris Chiasson
> Sent: 15. maj 2007 16:17
> To: Nicolas RAINARD
> Cc: 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 want to defend the stylesheet writers:
> 
> XSLT is, IMO, a functional programming language based largely on
> pattern matching. The source document trees can take many different
> forms and contain a variety of structures, while there are also many
> different output forms (for starters: fo, html/xhtml single/chunked).
> So, in this XSLT language, the stylesheet writers have to write a
> multi-input multi-output program and manage all the interactions of
> their transformations. This is not so easy to do, especially in one's
> spare time.
> 
> I think we should give them slack. Are the embedded tables killing us?
> No. Is the output highly accessible already? Yes.
> 
> On 5/15/07, Nicolas RAINARD <nicolas_rainard@yahoo.fr> wrote:
> >
> >  Dave Pawson wrote:
> > Nicolas RAINARD wrote:
> >
> >
> > This is why I spent a whole day to search how I could 
> resolve this. I used
> > the 5.0 XSLT and it seems it processes pretty much as the 
> 4.x do. I had a
> > glimpse in the XSLT2 snapshot, and I didn't find a XHTML 
> output in this
> > release. Maybe is it still automatically generated from the 
> HTML one? I am
> > not sure it is the best way, for transitional HTML and 
> strict XHTML have few
> > things in common.
> >
> >  Rather than aiming for valid XHTML why not check your output for
> > accessibility, then come back with questions?
> >
> >
> >
> >
> >  Moreover, the QandAset is rendered with definition lists 
> (<dl></dl>)
> > instead of ordered lists (<ol></ol>), which makes me puzzled...
> >
> >  What's wrong with DL? There are no accessibility issues there?
> >  The use of a table within a DL is unecessary though.
> >
> >
> >
> >
> >  Maybe am I wrong and then, could you tell me how I can get 
> a "pure",
> > table-less output?
> >
> >  You need to define 'pure'.
> >  You mentioned accessibility. Is that your goal?
> >
> >  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:
> > docbook-apps-unsubscribe@lists.oasis-open.org For
> > additional commands, e-mail:
> > docbook-apps-help@lists.oasis-open.org
> 
> 
> -- 
> http://chris.chiasson.name/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
> docbook-apps-help@lists.oasis-open.org
> 
> 


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