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


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/


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