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 (
)
> instead of ordered lists (
), 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
>
>
>
> Definition term 1
>
>
> Definition data 1
>
>
> Definition term 2
>
>
> Definition data 2
>
>
>
>
>
>
> 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
>
>
>
>
> FAQ question 1
>
>
> FAQ answer 1
>
>
>
>
> FAQ question 2
>
>
> FAQ answer 2
>
>
>
>
> 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
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/