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:
Preface
Into this:
Preface
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 (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 ,
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.
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
Definition term 1
Definition data 1
Definition term 2
Definition data 2
could be transformed to:
XHTML
Definition term 1
[docbook-apps] Re: *** GMX Spamverdacht *** Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
El Martes, 15 de Mayo de 2007 17:47, Bob Stayton escribió: > 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. IMHO, the first step would be to create a set of XHTML pages containing how each DB element, and its attributes, should be mapped into XHTML-1.1 + Ascessibility (valid XHTML-1.1 could be served as valid XHTML-1.0 if needed for browsers compatibility). Having that example mapping to know the actual changes needed, can be evaluated if that xhtml.clean parameter could be used, if the current xhtml/ templates could be full-changed to generate the new code, or if will be better to have two separate xhtml templates sets: the current one plus a new xhtml1.1 tree. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 To: Nicolas RAINARD ; 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. -- 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 Definition term 1 Definition data 1 Definition term 2 Definition data 2 could be transformed to: XHTML Definition term 1 Definition data 1 Definition term 2 Definition data 2 DocBook FAQ question 1 FAQ answer 1 FAQ question 2 FAQ answer 2 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > Definition term 1 > > > > > > Definition data 1 > > > > > > > > > > Definition term 2 > > > > > > Definition data 2 > > > > > > > > > > > > could be transformed to: > > > > > > XHTML > > > > > > > > Definition term 1 > > > > > > Definition data 1 > > > > > > Definition term 2 > > > > > > Definition data 2 > > > > > > > > > > > > > > DocBook > > > > > > > > > > FAQ question 1 > > > > > > FAQ answer 1 > > > > > > > > > > FAQ question 2 > > > > > > FAQ answer 2 > > > > > > > > > > > > could be transformed to: > > > > > > XHTML > > > > > > > > > > FAQ question 1 > >
RE: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
Chris is correct. Is the XHTML perfect or "modern"? Perhaps not. Does it produce useable, accessible output? Yes. The output we've managed to get from it for IONA's documentation looks very nice and is very workable. If people are so down on the output perhaps they could put some of their ideas into action... The people who developed and maintain the style sheets deserve both some slack and our appreciation. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Chiasson > Sent: Tuesday, May 15, 2007 10:17 AM > 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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 Definition term 1 Definition data 1 Definition term 2 Definition data 2 could be transformed to: XHTML Definition term 1 Definition data 1 Definition term 2 Definition data 2 DocBook FAQ question 1 FAQ answer 1 FAQ question 2 FAQ answer 2 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://chris.chiasson.name/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. 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 Definition term 1 Definition data 1 Definition term 2 Definition data 2 could be transformed to: XHTML Definition term 1 Definition data 1 Definition term 2 Definition data 2 DocBook FAQ question 1 FAQ answer 1 FAQ question 2 FAQ answer 2 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
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 Definition term 1 Definition data 1 Definition term 2 Definition data 2 could be transformed to: XHTML Definition term 1 Definition data 1 id="term02"> Definition term 2 Definition data 2 DocBook FAQ question 1 question> FAQ answer 1 answer> qandaentry>FAQ question 2 question> FAQ answer 2 answer> qandaentry> qandaset> could be transformed to: XHTML FAQ question 1 class="answer"> FAQ answer 1 id="qandaentry02"> class="question"> FAQ question 2 class="answer"> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
On Monday 14 May 2007, Nicolas RAINARD wrote: > Several years ago, you were talking about getting "Simpler XHTML output" > (initiating thread can be found at > http://www.cygwin.com/ml/docbook-apps/2005-q2/msg00230.html). > The whole discussion broached in accessibility and CSS layout, instead > of tables layout. It seems you started a new project: to make a brand > new forked XHTML XSL. > What is the current step of this project? Is it still undergoing or as > it been abandoned? For many reasons, I am very interested in getting > semantical, CSS styled XHTML output. > Thanks. > > Nicolas R. Good lord that's a while ago. :-) I'm afraid I've not done much with DocBook since then. I have one big DocBook project that I manage, but it hasn't had much in the way of changes since then save for me breaking my build environment on a regular basis. My XSLT skillz, and DocBook skillz in particular, have gotten a bit rusty in the interum. I'd love to see a cleaner, leaner, modern-structure XHTML output option for DocBook, but I've not had any time to work on it nor do I expect to for some time. (I'm off in PHP land speaking my native language. ) -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
Nicolas RAINARD wrote: I don't know how it goes for general layout, but I am absolutely sure a table layout is used for QandAset (what I wanted for my first DocBook). Yes that does seem rather redundant. It is simply to get the number aligned with the question. How do you think it should be done? para, number, nbsp, question? Doesn't seem too hard does it? Bob? Is this history or is there another reason for it? 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? regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
Dave Pawson wrote: Nicolas RAINARD wrote: Several years ago, you were talking about getting "Simpler XHTML output" (initiating thread can be found at http://www.cygwin.com/ml/docbook-apps/2005-q2/msg00230.html). The whole discussion broached in accessibility and CSS layout, instead of tables layout. Bob may correct me, but AFAIK docbook doesn't use table based layout and any CSS additions are the authors, not a part of the standard docbook formatting, though provision is made for CSS usage. I don't know how it goes for general layout, but I am absolutely sure a table layout is used for QandAset (what I wanted for my first DocBook). 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. Moreover, the QandAset is rendered with definition lists () instead of ordered lists (), which makes me puzzled... It seems you started a new project: to make a brand new forked XHTML XSL. What is the current step of this project? Is it still undergoing or as it been abandoned? For many reasons, I am very interested in getting semantical, CSS styled XHTML output. So are many of us, which is why we choose docbook! Maybe am I wrong and then, could you tell me how I can get a "pure", table-less output? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docbook-apps] To Rene Hache, Larry Garfield, Bob Stayton, Jirka Kosek - About a former XHTML accessiblity project
Nicolas RAINARD wrote: Several years ago, you were talking about getting "Simpler XHTML output" (initiating thread can be found at http://www.cygwin.com/ml/docbook-apps/2005-q2/msg00230.html). The whole discussion broached in accessibility and CSS layout, instead of tables layout. Bob may correct me, but AFAIK docbook doesn't use table based layout and any CSS additions are the authors, not a part of the standard docbook formatting, though provision is made for CSS usage. It seems you started a new project: to make a brand new forked XHTML XSL. What is the current step of this project? Is it still undergoing or as it been abandoned? For many reasons, I am very interested in getting semantical, CSS styled XHTML output. So are many of us, which is why we choose docbook! regards -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
